Earlier, Brian Carpenter wrote: % Er, right, which I guess is why Plan A for IPv6 has always been % pure PA, and use multiple prefixes on a site that has multiple % ISPs. But the premise in RRG is that this won't fly, and hence we get % this hassle. If Bill is right about source filtering being sacrificed % as a result, there seems to be a biggish fly in the ointment.
It is possible there is an opportunity for the "IPv6 Advocate" community to do some actual technical training and educational work on how that "Plan A" above would work. At present, there is a lot of user demand on the RIRs for PI space. If that is simply a matter of users not understanding how to make the "Plan A" work, then training/education might change things. For what its worth, the perception is that IPv6 renumbering (e.g. if an upstream provider link fails for a multi-homed site using PA space) is too hard -- and existing TCP/UDP sessions fail if the PA address being used belongs to a PA whose link to the multi-homed site fails. Quite separately, TCP sessions bind to the whole IPv6 address, not just to an identifier. So when one upstream link fails, the two nodes can still reach each other via an address in the other upstream provider's PA block -- HOWEVER the TCP session will fail after timeout seconds. SCTP doesn't have this issue, but TCP/UDP definitely do today, which is why splitting the IPv6 address into distinct Locator and Identifier components would be helpful. (At this point, I will refer to the ILNP draft for one possible way to do that; HIP is a different way to do that with different tradeoffs; one can implement something very like HIP using ILNP, but one cannot easily implement the general ILNP approach in HIP as near as I can tell). Yours, Ran [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
