Louis, Kavé,
je ne croyais pas si bien dire; Fred Baker soi-même en vient à la
proposition que je défends depuis des années d'une entête IPv6
amovible pour IDv6. Cela me permet comme je l'expliquais dans un
précédent mail d'utiliser aussi bien un header IPv6 ou un nom de
domaine pour supporter un adressage local IDv6 (c'est à dire
l'Interface ID traîté comme une adresse ayant un scope universel)
jfc
At 20:03 06/12/2010, Fred Baker wrote:
I posted
ftp://ftpeng.cisco.com/fred/nat66/draft-mrw-nat66-00-01-diff.html
ftp://ftpeng.cisco.com/fred/nat66/draft-mrw-nat66-01.html
to Margaret for comment. She might tell me to scrap it - it's a big
change from draft-mrw-nat66-00. However, I'd appreciate comments on
it from this list.
Fred,
we certainly carefully review this. This seems to be what we call for
for years and documented for an ITU /3 block in 2005. This way the
local part of the address we call IDv6 is uncoupled from IPv6 by a
function. This brings stability to both side and certainly go with
the IUI (Intelligent/Internet Use Interface) concept derived from
IDNA2008 consensus.
Thanks
jfc
The big changes are:
- Change the acronym "NAT66" to "NPTv6", so people don't read
"NAT" and MEGO.
- Change the term used to refer to the function from "NAT66
device" to "NPTv6 Translator". It's not a "device" function,
it's a function that is applied between two interfaces. Consider
a router with two upstreams and two legs in the local network;
it will not translate between the local legs, but will translate
to and from each upstream, and be configured differently for
each of the two ISPs.
- Comment specifically on the security aspects.
- Comment specifically on the application issues raised on this
list.
- Comment specifically on multihoming, load-sharing, and asymmetric
routing.
- Spell out the hairpinning requirement and its implications.
- Spell out the service provider side of Address Independence;
-00 focuses on the edge's view
- Detail the algorithm in a manner clearer to the implementor
(I think)
- Spell out the case for GSE-style DMZs between the edge and the
transit network, which is about the implications for the global
routing table.
- Refer to draft-ietf-v6ops-cpe-simple-security
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
comptoir mailing list
[email protected]
http://cafedu.com/mailman/listinfo/comptoir_cafedu.com
