Re: IPv4 outage at next IETF in Chicago

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In message <212835829.114144965.1485306337275.JavaMail.zimbra@xxxxxxxxxxxxxxx>,
 Franck Martin writes:
> 
> ----- Original Message -----
> > From: "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx>
> > To: "Franck Martin" <franck@xxxxxxxxxxxxxxx>, "IETF" <ietf@xxxxxxxx>
> > Sent: Tuesday, January 24, 2017 4:33:22 PM
> > Subject: Re: IPv4 outage at next IETF in Chicago
> 
> > On 25/01/2017 12:11, Franck Martin wrote:
> >> I think it is time to move to the next level of IPv6 deployment.
> >> 
> >> Ideally the IETF WiFi network should now only provide the following 2 netw
> orks:
> >> 1)IPv6-only
> >> 2)IPv6-only with NAT64
> >> 
> >> The later should be the default network.
> >> 
> >> However you would say, well some stuff will break, some non technical
> >> people will use the IETF network and may have a bad experience, etc...
> >> 
> >> So to be conservative but at the same time futurist and like it was
> >> done a few years back, why not create again an IPv4 outage of a few
> >> hours where the above 2 networks would be the only networks available?
> > 
> > That would be a good way of damaging IETF productivity for a few hours.
> 
> Do you have evidence of applications not running in a NAT64 environment? I'm 
> interested to know them.

Anything that really wants to know is AAAA records exist or not.
You don't run NAT64 w/o DNS64 and that munges with DNS answers.
Lots of what I do would break because of that.  I need to know the
truth, not the lies from DNS64.  And yes I have written DNS64 code.

> > And for what? Moving away from the mainstream coexistence mechanism (dual
> > stack),
> > to a mechanism known to be intrinsically defective (NAT). I don't see
> > the point.
> 
> I fail to see how NAT is intrinsically defective, since it is used
> successfully by everyone...

No one successfully uses NAT.  They just put up with its limitations.
There is a big difference.  That said there will always be limitations
delivering IPv4 going into the future.

> Nevertheless, the goal here is to get the Internet designers (IETF) to
> have operational experience on what needs to be fixed.

Step 1.  Stop saying to use NAT64.  There are other ways to provide
IPv4 as as a service with IPv6 only all the way to the node.

> When the IPv4 outage happened a few years back, it gave a serious impetus
> in getting IPv6 totally mainstream on many platforms.
> 
> IAB encourages IPv6: https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
> 
> However going IPv6-only can only be done in walled gardens. There still will 
> be many environments with IPv4 only. A solution here is to move networks to
> NAT64, so you only need to support IPv4 at the edges...

No.  The goal is IPv6-only access networks with IPv4 as service,
then IPv6-only within the home / enterprise with IPv4 as a service.
Note this doesn't specify a solution.

> Yes creating an outage for the sake of an outage is pointless, experience on 
> what works and not work needs to be recorded.
> 
> May be the first step instead of doing an outage is to have as default
> a NAT6 4 network at IETF meetings and a dual stack network for the people
> that experience issues.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@xxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]