hi,
On 11/8/2011 5:17 PM, Ole Troan wrote:
...
the consequence of that is that the destination IPv6 address will change for
every flow.
If a source ignores the destination PSID length, yes, IPv6 addresses of two
flows going to the same CE may differ.
But so what?
- The IPv4 packet submitted to the CE NAT is the same as the source IPv4 packet
- The final destinations behind the NAT may differ too
the MAP node cannot any longer listen to a single IPv6 address for MAP traffic,
but has to intercept packets for a whole prefix.
- BR's of double translation have always had this property.
- Talking with Mark townsley, I got the understanding that this wasn't a real
problem, at least with IOS.
everything can be _implemented_, that's not the point.
=> Clarifying this point would IMHO be useful.
it is clearly requiring bigger changes to tunnel code. which unlike NAT code is
attached to 'one' endpoint.
it makes co-existence of a MAP endpoint and native IPv6 nodes within a single
/64 much harder.
+ 1
Cheers,
Jacni
let us turn this around. what's the point in embedding a new set of CNP bits in
the IPv6 address, when the L4 checksum can be incrementally updated. that's
what everyone has existing code to do already...
cheers,
Ole
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
