Le 27 oct. 2010 à 14:14, Keith Moore a écrit : > IMO, a minimum requirement for any v6 NAT approved by IETF is that hosts/apps > MUST have a way to determine the external/global addresses associated with a > connection without needing an external server in global address space for ICE > or similar tricks. > This mechanism MUST be the same mechanism for all standard NATs.
I agree with this, but then host modifications are needed anyway. Then a key supposed advantage of NAT66 (stateful or stateless) over solutions that depend on host upgrades vanishes. Do you agree? Besides, the technical analysis below of the relationship between NAT66, PA-prefixes, and multihoming, doesn't depend on hosts knowing or not their addresses. I do hope someone will eventually comment its technical contents. > People need to stop insisting that hosts and apps don't need to know their > addresses.` Yes, some apps need it, and therefore some hosts do need it. Regards, RD >> - If a private-site network has two CPEs giving access to two ISPs with PA >> prefixes, the CPE via which a packet goes to the Internet depends on the >> intra-site routing. >> - If intra-site routing DOESN'T make sure that all packets from a given host >> always go to the same CPE, then TCP connections will be broken because: >> . packets that go via a CPE different from that traversed by the the SYN >> packet will be received with a different source address >> . they will then be discarded at their destination because they have a >> different source address than that of the 5-tuple that identifies the >> connection. >> . the available tool to work with several source addresses, SHIM6, can't >> help because, due to NAT66, hosts don't know their global addresses. >> - If intra-site routing DOES make sure that all packets from a given host >> always go to the same CPE, incoming connection that come via the other CPE >> will be broken because outgoing packets will never have the right global >> source address. >> _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
