Hi Ondrej,

Yes, is as you said, an SSID (for example CLAT), which looks like the same as a 
CPE that a residential or SME can have in his place.

The IPv6 traffic will be forwarded natively.

The IPv4 traffic that uses DNS will be translated by the NAT64 (which already 
exist in the NCC network), as if you were connected to the NAT64 SSID.

The different is the IPv4 traffic that has literal IPv4 addresses. In the NAT64 
case, this is just broken, don’t work (skype, web sites with IPv4 addresses 
instead of names, etc.).

So, when using 464XLAT, the IPv4 traffic that has literal addresses, will be 
translated like a combined NAT44-NAT46 by the CLAT, then forwarded to the 
NAT64, which translate it to IPv4 as usual.

It doesn’t harm the packets, is already being used in the bigger cellular 
networks, providing IPv6-only in the WAN link.

The participants should not “notice” difference, which is precisely what we 
want to demonstrate.

Your explanation is right in the sense of “this” network, but think in the 
access network of the ISP.

The only difference is if you need a “public” IPv4 for some special incoming 
traffic, but this is not a normal scenario in residential networks with use 
CGN, right? The point here is to show that instead of using CGN and relying 
still in IPv4 is not needed in the wired world, the same as isn’t needed in the 
cellular world. We just need to have a transparent dual-stack in the LANs.

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6-wg <[email protected]> en nombre de Ondřej Caletka 
<[email protected]>
Responder a: <[email protected]>
Fecha: viernes, 24 de marzo de 2017, 10:48
Para: <[email protected]>
Asunto: Re: [ipv6-wg] including a CLAT (464XLAT) SSID in RIPE meetings

    Dne 22.3.2017 v 22:54 JORDI PALET MARTINEZ napsal(a):
    > With 464XLAT (or MAP), you avoid deploying CGN, which is a high cost, and 
you provide the *same* functionality that today “regular” customers 
(residential, SMEs, even many big companies that don’t have to export IPv4 
services outside their LANs). If we demonstrate this “live” in the RIPE meeting 
network, I think we can change some of the participant’s minds, and I believe 
the cost of that is really small, may be a couple of hours of one of your OPS 
team colleagues, as I’ve already done the work and I’m happy to help them on 
testing in their lab, document what I’ve done (already working on that), and
    > anything else they may need.
    
    Hi Jordi,
    
    can you please elaborate some more about how it should look like from
    the technical point of view? Because as I now read it, I just imagine an
    SSID with dual-stack IPv6/RFC1918 IPv4, where the IPv6 will go natively,
    and IPv4 would be:
    
     1. translated from IPv4 to IPv4 (can be part of step 2)
     2. translated from IPv4 to IPv6
     3. forwarded as IPv6 to another (or even same(!)) box
     4. translated from IPv6 to IPv4
     5. translated from IPv4 to public IPv4 (can be part of step 4)
    
    My bet is that this very complex translating exercise will not harm the
    packets much more than just a single NAT (except some latency, maybe).
    And the wireless access network users will just see a dual-stack network
    with NATed IPv4, which is actually AFAIK the most common way of
    deploying IPv6 nowadays.
    
    Now the question is: How would you explain to an IPv6-newbie what is the
    difference between `ripemtg` and `ripemtg-464xlat' networks?
    
    My explanation would be like: "Those networks work exactly the same way,
    but in the latter case, there is a one meter long cable back in the ops
    room, where all the traffic from the latter network is carried as just
    IPv6 protocol. Then it's translated back to IPv4 for the Internet"
    
    But that's probably not the explanation I would like to hear as an
    IPv6-newbie. Am I missing something?
    
    Also:
    > Having just a NAT64 gives the impression to the people that today you can 
deploy IPv6-only access to customers and we know is not the case, because the 
app.
    
    Not a problem with today's smartphones. All iPhone apps has been fixed
    thanks to Apple's pressure, a lot of recent Android (6.0+) devices
    features CLAT integrated that works even via Wi-Fi. If Microsoft pushes
    CLAT into some future version of Windows, the problem with apps would be
    mostly gone and IPv6-only access networks would be fully usable even for
    end-stations.
    
    Cheers,
    Ondřej Caletka
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.




Reply via email to