Le 2012-02-06 à 09:33, Ole Trøan a écrit : ... >>> MAP is more flexible with regards to not depending on the V octet. >> >> (a) Which flexibility? To do what? > > supports arbitrary end-user IPv6 prefix length, without regard for 'magic > bits' in the interface-id.
If you have a use case where CEs need longer that /64 prefixes for native IPv6, I will look at them and comment. If CE IPv6 prefixes longer than /64 are only used to convey CE IPv4 addresses, I don't see the problem of having these addresses always starting at bit 80. (It simplifies at least documentation and maintenance. Standardization is sometimes making simplifying choices when nothing functional is lost by making them.) >> (b) Do you negate that: >> - with MAP as is, an IPv6 site may have to change its assignment of subnet >> prefixes to support MAP > > only if the first subnet in the end-user IPv6 prefix is used by another > internal router, that isn't going to act as a MAP CE. "Only if", yes, but indeed in this case. Having never to renumber is better than having to renumber in some cases, and better than having no residual IPv4 service on some subnets. > >> - This is never needed with 4rd-U, thanks to the V octet. > > renumbering is in any case going to happen in the home, Not understood. Renumbering should be avoided if it can (IMHO). > and we have to design our protocols to deal with it. > can we just agree to disagree on the V-octet, and not spend any more working > group time on it? Technical debate is finished if: - You accept that never having to renumber is a useful feature, compared to having to do it in some cases. - You avoid statements like "renumbering is in any case going to happen in the home" to negate value of renumbering avoidance. > it would be good if you wrote up a more detailed analysis in a separate > draft, so the considerations are kept somewhere. I will write a comparison table. RD > > cheers, > Ole > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
