While most of the discussion about killing NAT66 is happening on the
IETF list, we have a much more constructive discussion going on in
behave regarding how to define an IPv6 NAT that will meet the needs of
network administrators and end-users, while being less destructive to
the Internet architecture, local network connectivity, transport layer
protocols and applications than current IPv4 NA(P)Ts. It is not clear
that we can achieve everything that we want to achieve yet, but
wouldn't it be cool if we did?
If folks would like to join that discussion, please read the following:
NAT66 Internet-Draft: http://tools.ietf.org/html/draft-mrw-behave-nat66-01
NAT66 Presentation (updates the draft):
http://www.ietf.org/proceedings/08nov/slides/behave-14.pdf
Then, come talk to us on the behave WG mailing list: behave(_at_)ietf(_dot_)org,
To Subscribe: behave-request(_at_)ietf(_dot_)org, In Body: subscribe.
All feedback and opinions are welcome!
Margaret
On Nov 26, 2008, at 12:14 PM, Hallam-Baker, Phillip wrote:
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.
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.
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Eric Klein
Sent: Mon 11/24/2008 5:56 AM
To: Fred Baker
Cc: IAB; behave(_at_)ietf(_dot_)org WG; IETF Discussion; alh-ietf(_at_)tndh(_dot_)net;
IESG IESG
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
applicationdevelopers
On Sat, Nov 22, 2008 at 7:07 AM, Fred Baker <fred(_at_)cisco(_dot_)com> wrote:
On Nov 21, 2008, at 9:39 PM, Tony Hain wrote:
The discussion today in Behave shows there is very strong peer-
pressure group-think with no serious analysis of the long term
implications about what is being discussed.
Yes, there is a very clear anti-NAT religion that drives a lot of
thought. It's not clear that any other opinion is tolerated.
Fred,
I pesonally would be open to a real discussion about the needs and
then about the solution. But for now NAT has taken on religious
connotations with those who are for it being as single minded as
those who are against it.
We need a team made up of both sides to sit down, spell out what are
the functions of NAT (using v4 as a basis) and then to see if:
1. If they are still relevant (like number shortage from v4 is not
the same issue under v6 for example)
2. Do they already exist in v6 without adding NAT
Then we need to check:
1. Is there is a solution by using NAT
2. Is there is a better solution than using NAT
Only then can we make a proper and informed decission on what is
needed and what is unneeded legacy.
Eric
_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf