Nice summary ;-)

Let’s put in this way regarding the IETF SSID and “dogfooding”:

B allows us to *detect* what will fail when we go to A, but not creating the 
users a lot of problems and waste of time, complains to the NOG, etc.

Then, once we have warned those services and apps that fail, exposing publicly 
the results of what is subjected to failure if we go to A, keep using B in our 
network at each following IETF, see the evolution of those “detected failures” 
and may be in one year from one decide if we want to move to A.


-----Mensaje original-----
De: sunset4 <> en nombre de "Heatley, Nick" 
Responder a: <>
Fecha: lunes, 17 de octubre de 2016, 18:04
Para: "" <>, 
"" <>
Asunto: Re: [sunset4] Sunset4 work

    A thought provoking discussion.
    I don't think the specific transition technology matters so much as the 
"family" it falls into. 
    What matters is whether IETF wishes to showcase IPv6-only down to the 
customer client devices (and then to harvest the expected client issues, IPsec 
failing?), or whether it wishes to showcase "local dualstack on the 
small-stub-network, with an IPv6-only provider connection" to show how 
small-stub-networks could be connected in the future.
    Let me explain (longer answer).
    In a number of years' time, as providers run out of IPv4 publics, edge 
"networks" will be brought on with only global IPv6 addressing available as the 
persistent identifier for connected endpoints. (I am assuming in Sunset4 we can 
agree on that).
    But what addressing is within the edge network?
    1. For large edge networks where private addressing numbers are not 
sufficient to meet the number of connected devices, they will need to go 
IPv6-only, as we have seen with large mobile operators, and learnt with 
Microsoft Enterprise, Facebook etc. These networks all say private IPv4 
addressing is not sufficient.
    2. For smaller enterprise edge networks then they may well be sitting and 
waiting, or following the above, time will tell.
    3. For "small-stub-networks" (SSN), where the number of connected devices 
is manageable then clearly IPv4 private addressing is sufficient.  Public Wifi 
access being a perfect example of SSN, or any model using a consumer CPE I 
suppose. So this is the question for sunset4:
    (A) Do we wish to advocate IPv6-only in this SSN scenario? in which case 
all current and future client issues must be resolved (IPv4 literals) such that 
the clients work in the absence of an IPv4 address? This case is typified by 
NAT64/DNS64, other transition mechanisms are available.
    (B) Do we wish to advocate dualstack networking to the client in this SSN 
scenario? Avoid client issues by providing them with a GUA and a IPv4 private? 
In which case the transition technology (held within the CPE) needs to enable 
dualstack on the access side but on the provider side, cope with only an 
IPv6-only provider connection. 464xlat in the CPE (like 464xlat based tethering 
from a cellular handset) is an example of a transition technology in this 
family, others are available.
    Both of these SSN approaches assume that within the core of the internet 
their remains the legacy IPv4-only content, which seems valid for "consumer 
electronics networking" in general.
    They differ on how we expect consumer electronics networking to evolve (or 
how we *want* it to evolve). We could advocate both for sure, but not sure if 
that helps move sunset4 forward!
    My opinion, take it or leave it, is that pragmatically, a SSN vision based 
on (B) is less problematic. It is less dependent on moving a whole collection 
of Consumer Electronics away from today's deficient state, because (A) 
essential demands they work in absence of IPv4. This requires concerted effort 
to remove the "IPv6-only" mode bugs that we know exist.
    The biggest problem with (A) is that you cannot make the network model the 
compulsory model, until the majority of Consumer Electronics is fully ready, 
which creates another network provider chicken-egg problem. You can do OS by OS 
(something that a popular smartphone and PC vendor is attempting with 
IPv6-only, NAT64) but network providers don't wish to create individual network 
paradigms for each OS.
    Then we look back at 2., above. Enterprises moving to IPv6-only - do we 
have some need and obligation within Sunset4 to push (A) to avoid Enterprises 
being trapped in an IPv4 world? To leave dualstack in one part of the edge 
(SSN) - does it undermine the benefits we are telling enterprises on IPv6-only 
e.g. removal of dual address complexity. Personally I believe this is only 
really an issue in practice where the enterprise is so large that the 20M 
private addresses are not sufficient for their organisation - and I think such 
enterprises are big enough to progress this issue themselves if they wish 
IPv6-only to work for them. But if (A) is consensus then Sunset4 should start 
to define the client requirements for absence of IPv4 in a SSN. And unlike 
provider networks, enterprise networks own and manage the end to end network 
use case themselves.
    The other concern for me about (A) is that I have already oversimplified 
devices as "consumer electronics" as though they only fall into the hands of 
consumers in consumer usecases.
    One of the big issues I foresee with the IPv6-only approach of certain OS 
vendor(s) is that something like a smartphone can be an end device with its 
network interface servicing "on board Apps" (typical mobile connectivity), but 
it can also be a network gateway when used for tethering or "internet sharing". 
The end device (the device tethered on the end of the wifi link) may actually 
be in an enterprise use case ("VPN into an office network" for example). By 
making the SSN IPv6-only we may risk placing requirements on the enterprise 
network (i.e. outside-in connectivity like the VPN concentrator, may need 
certain functionality to terminate an IPv6 IPsec VPN etc.). We may need the 
requirements for (A) not just be about end devices but also coordinating 
requirements for various gateways in enterprise networks? If you believe that, 
it is another serious chicken-egg problem; do we need enterprise networks 
upgraded before we can move to a solution for SSNs? (See the IPsec comments in but in the general case IPsec 
VPN is a fail, right?)
     I am very much in favour of the family of transition technologies that 
enable (B).
    SO I inferred a definition of the term SSN to suit my needs in this mail. 
What is really boils down to is that edge networks need some sort of CPE or 
Gateway to the provider network. Do we want that CPE to provide dualstack 
locally or IPv6-only when the provider addresses run out.
    Back to the IETF SSID, what SSN vision do you wish to showcase? (I'd prefer 
a choice for long term rather than "for next meeting" and I'd go for something 
like Jordi's 464xlat in the CPE! Choose wisely :-)
    If an IPv6-only SSID is just to showcase IPsec VPNs still failing, it is a 
bit of a waste of people's time).
    -----Original Message-----
    From: sunset4 [] On Behalf Of JORDI PALET 
    Sent: 07 October 2016 21:02
    Subject: Re: [sunset4] Sunset4 work
        On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ" 
< on behalf of> wrote:
        >This is what I’m proposing. May be I miss explained it.
        >NOT asking EVERY device in our network to HAVE 464XLAT client (CLAT), 
but having ONLY our “CPE” to have it.
        >Nodes will not notice anything.
        >This is what is going to happen in the future in most of the networks 
because they will not have IPv4 for every customer, so why not trying it 
ourselves? Already happening in many cellular networks, like in US, which are 
close to have 60% IPv6 traffic already.
        You think 464xlat is what's going to happen in the future in most 
        Mobile networks, yes, it's a primary transition mechanisms.
        Wi-fi networks operated by ISPs or enterprises are more likely to use 
NAT64, DS-Lite, or MAP, based on what I'm seeing people working on.
    I disagree in several points:
    1) 464XLAT is not only for cellular networks, just read the draft.
    2) It has been implemented by some CPE vendors. It can be run in Virtual 
Machines as well.
    3) I’ve tested it in several ISP network. Trials at the time being, but 
coming into production.
    4) NAT64 is WORST than 464XLAT. NAT64 doesn’t sort out the problems for 
apps using literals. 464XLAT sort it out. Yes, NAT64 was developed first, but 
that’s the reason 464XLAT was needed, because not everything was working in 
    5) If you don’t trust 464XLAT, then you can’t trust in NAT64, because is 
just an “incomplete” version of 464XLAT.
    I agree with you that DS-Lite and MAP are other choices, comparable with 
464XLAT. They will be a better test, for sure than just NAT64.
    If you want something more lightweight than DS-Lite, probably will be 
better to use lw4o6. 
    Just to make sure it has been understood: I’m not asking to implement 
anything in the clients of our network. Nobody needs to install anything. We 
just need to have a VM or a set of them if we don’t trust on the hardware 
performance, as the “CPE router” of the IETF SSIDs that we want to run this. 
This VM need to incorporate the CLAT client. Our network will behave as an 
enterprise network which as only IPv6 native connectivity to Internet, and the 
ISP (in this case our own network) will running the PLAT (NAT64/DNS64).
    If you still want to try the NAT64 one more, you can have the NAT64 SSID, 
that has been already tested in all the RIR meetings, etc. But this will not 
run any apps that use literals, old APIs, etc.
        My fear with 464xlat is that it's largely untested in environments like 
the IETF. I would not support making it the default SSID. We've had a NAT64 
SSID for several years; it could be promoted to default, if we can demonstrate 
with confidence that everyone can still get their work done.
    ⇒ NAT64 as default is not and option. It breaks everything using literals. 
We want to have a good experience I guess, and be able to detect what will fail 
in the future (logging CLAT and NAT64/DNS64 usage), not break the IETF network.
        >-----Mensaje original-----
        >De: sunset4 <> en nombre de Philip Homburg 
        >Responder a: <>
        >Fecha: viernes, 7 de octubre de 2016, 12:04
        >Para: <>
        >CC: "Bjoern A. Zeeb" <>
        >Asunto: Re: [sunset4] Sunset4 work
        >    In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote:
        >    > Nastygram.  So make the default IETF SSIDs IPv6-only or (+NAT64)
        >    > if you want.  Then have the ietf-legacy network, which would give
        >    > you IPv4 and a portal page penalty that you have to state the 
        >    > why you have to use this network and cant live on the default 
        >    > Id be so curious to see what happens when people finally have to
        >    > start thinking about it.. and open internal tickets ..  It was
        >    > great fun doing it 6-ish years ago, ..
        >    Personally, I consider offering NAT64 over wifi quite absurd. The 
        >    way to provide access to legacy IPv4 is some form of NAT4. How it 
        >    transported over the rest of the network is upto the network 
operator. But
        >    the obvious interface is RFC 894.
        >    So on networks that promote NAT64 (FOSDEM has this setup for quite 
a number of
        >    years now) I just connect to the legacy network. Their legacy 
network has
        >    perfectly fine IPv6, so I consider it way better than the NAT64 
        >    'everybody' likes to push.
        >    For the specific mobile weirdness, NAT64 make sense. But 
everywhere else,
        >    requiring every device to have 464xlat to deal with IPv4 literals 
is just
        >    bad engineering. If your backbone is IPv6-only, then the obvious 
        >    is to deal with this in CPEs, wifi access points, etc. Not to 
require all
        >    hosts to know the details of your network.
        >    _______________________________________________
        >    sunset4 mailing list
        >IPv4 is over
        >Are you ready for the new Internet ?
        >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.
        >sunset4 mailing list
    IPv4 is over
    Are you ready for the new Internet ?
    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.
    sunset4 mailing list
    This email contains BT information, which may be privileged or 
confidential. It's meant only for the individual(s) or entity named above. 
    If you're not the intended recipient, note that disclosing, copying, 
distributing or using this information is prohibited. 
    If you've received this email in error, please let me know immediately on 
the email address above. Thank you.
    We monitor our email system, and may record your emails.
    EE Limited 
    Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, 
AL10 9BW
    Registered in England no: 02382161
    EE Limited is a wholly owned subsidiary of:
    British Telecommunications plc
    Registered office: 81 Newgate Street London EC1A 7AJ
    Registered in England no: 1800000
    sunset4 mailing list

IPv4 is over
Are you ready for the new Internet ?
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.

sunset4 mailing list

Reply via email to