RE: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers

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

 



Title: RE: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers


Yes, we all know that it is much easier to get O/S vendors to fix their billion plus lines of code and the apps vendors to fix their million plus lines of code than it is to deploy a $50 NAT box.

What you are proposing here is that we bell the cat instead.


-----Original Message-----
From: Mark Andrews [mailto:Mark_Andrews@xxxxxxx]
Sent: Wed 11/26/2008 5:40 PM
To: Hallam-Baker, Phillip
Cc: Eric Klein; Fred Baker; behave@xxxxxxxx WG; IAB; IETF Discussion; alh-ietf@xxxxxxxx; IESG IESG
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers


In message <2788466ED3E31C418E9ACC5C316615572FFBAB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
om>, "Hallam-Baker, Phillip" writes:
> This is a multi-part message in MIME format.
>
> Eric,
>
> The problem here is that you assume that the IETF has decision power
> that can magic away NAT66. Clearly it did not for NAT44 and will not for
> NAT66.
>
> So the real question for App designers is:
>
> 1) Should they design protocols that assume no NAT66
> 2) Should they regard the assumption that there is no NAT6 as a design
> fault that may lead to lack of interoperability.
>
> The only way that the effort being expended to kill NAT66 makes any
> sense is if the idea is to allow this type of argument to be rulled out
> of scope as similar arguments were ruled out of scope when they were
> brought up in existing protocols that simply do not work properly
> because the design was intentionally made to be unfriendly to NAT.
>
> If we recognize that there is no consensus that applications that are
> not NAT66-agile will work in future then we should agree that the
> reasonable default requirement for an apps WG should be that it should
> build a protocol that is NAT66 tolerant. But I suspect that there will
> be severe pushback against that.
>
>
> Peter Dambier is right in this case,
>
> I would NAT66 my network for the simple reason that very few endpoint
> devices actually tollerate a change in the IP address without at a
> minimum a service interruption. Since I cannot guarantee that my IPv6
> address from my ISP will never change I am going to NAT66 my internal
> network for the sake of having static numbering inside the network.

        And if you stop thinking IPv6 == IPv4 + big addresses and
        start thinking multiple IPv6 addresses including a ULA IPv6
        address + RFC 3484 you get local address stability without
        needing a NAT.  You use ULAs for internal communication and
        global addresses for external communication.

        This isn't future stuff, you can do this today.  You can
        renumber your external addresses daily and keep internal
        sessions up for weeks.

> The more infrequent you posit the need for renumbering is, the greater
> my reluctance to allowing it will become. If you have a network event
> that happens only once a year it is going to mean a very serious
> disruption when it happens. DHCP only solves some of the problems, I am
> still effectively forced to perform a reboot, I will lose connections
> and this will cost me real time and money to fix.

        If your OS requires a reboot when you renumber get a real OS.
        If your apps require that they restart when you renumber get
        your apps fixed.

        Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@xxxxxxx

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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