[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach



Rémi Després wrote:
> Thanks for your detailed comments.
> 
> Tony Hain wrote:
> > Problems:
> >
> > 1) 'pure' tag makes a questionable assumption in light of unresolved
> and
> > continuing RIR discussions about changing the status of 240/4.
> >
> OOPS
> There is a typo: 1110 as most significant bits is 224/4 (not 240/4 as
> written once).
> Apologies.

The tag is a waste to begin with, so fixing which block it talks about
doesn't really solve the problem.

> > 2) causes ISPs to allocate unnaturally large prefixes to pops to
> accommodate
> > a mostly unused 32-bit field
> >
> See the answer to Gert Doering:
> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00345.html

A quick hack that is deployed does not mean this is a good design. The
deployment could also have taken one /38 and handed out /48's to customers,
then put all the native IPv6 sites in a different /38 (note: both fit well
within the /32). Any CPE could find the others within the ISP because the
/38 matches, and anything else would go to the relay. No need for a magic
flag. No need for oversize allocations to deliver undersize prefixes to
customers. 

> > 3) the 3.5 discussion about accepting prefixes from other ISPs that
> might
> > contain a 6rd anycast is just wrong. First there is no way for an ISP
> to
> > know which prefix its peer is using for a 6rd relay. Second, there is
> no
> > reason to preclude it since the IPv6 6rd prefix would not match for
> their
> > sites, and the local CPE would not be configured for the other ISP's
> > anycast, so the local CPE would never be attempting to send to the
> other
> > ISP's 6rd anycast relays even if there is a route.
> >
> >
> There must be a misunderstanding.
> An ISP never needs  to know 6rd anycast addresses of other ISPs.
> Routes an ISP has to make sure to refuse, if received by accident or
> malevolence, are routes to their OWN 6rd anycast prefix.
> It can be made clearer in the next version.

   For an ISP to guarantee proper routing of IPv6 packets going from its
   IPv4 sites to other ISPs, its IPv4 infrastructure SHOULD NOT accept
   from other ISPs IPv4 routes that include the 6rd ISP anycast address.

If this is just saying 'don't accept your prefixes from another provider',
it is not clear that you even need to say that. 

Tony