Hi Ole, I just found I didn't answer this mail directly. In case other exchanged mails wouldn't have answered the point, please see below.
Le 1 oct. 2011 à 04:31, Ole Troan a écrit : > Remi, > >>>>> what are the requirements for a globally unique interface-id? how is it >>>>> going to be used? >>>>> both for encapsulation and translation? >>>> >>>> In both cases, the CE node can recognize 4rd packets, and process them as >>>> such, without preempting any IID value that might be a legitimate value >>>> for a host behind the CE. >> >> This is my answer to your first (double) question. >> If it is not enough, as suggested below, please explain what you don't >> understand. > > I specifically do not want a solution that changes forwarding behaviour for > _all_ IPv6 packets. > e.g. looking at 24 bits in the middle of an IPv6 address is such a change. The proposed solution doesn't impact the forwarding behavior of any function that isn't specifically a 4rd function. > I don't understand what requirements you are basing this 'solution' on. Design objectives are listed in Sec 4. They include: - Possibility of IPv6 routing plans that have no constraints related to IPv4 residual deployment. - Possibility (even in this case) to assign differentiated sharing ratios. This is achieved by having lengths of port-set IDs determined by lengths of CE IPv6 prefixes. > if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of > the delegated prefix. then why do you need any of that? I don't completely follow the proposal, and what you want to avoid. In any case, the discussion should now focus on the proposed unified address mapping. Agreed? > note that I'm not arguing against having a defined IID for dIVI/4rd, that's > nice for pretty printing like what we do for ISATAP. Good, then. Cheers, RD > > cheers, > Ole > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
