Re: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt

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

 



On 16-sep-2005, at 23:55, Bill Manning wrote:

i am convinced that the IETF has no business telling me what routes i may or may not accept from or send to my peers, with the exception of prefixes of undefined BEHAVIOUR, much like the IPv4 class "E" space.  That said,  if these are Guidelines, as the title suggests, then there is no place for  the "MUST/MAY/SHOULD" keywords.   Even now, within the RIR and operational communities, there are discussions on changing the /48 boundaries.

I think the IETF has more business telling people what they should and shouldn't do in routing than the RIRs. They are clearly not up to the task. For instance, for the past two years (if not longer), the ARIN policy ( http://www.arin.net/policy/nrpm.html#six43 ) says that it's ok to filter at a /32 boundary while they also give out /48 prefixes ( http://www.arin.net/reference/micro_allocations.html ).

Also, the fact that the RIRs get to make up their own address policies is a very bad idea because there is just one global routing table so clearly, if all five of them have different policies, then four of those are sub-optimal. And it makes it very hard for people who care about the long term stability of the internet to apply backpressure against the greediness of RIR members that just want their own address block and the consequences be damned.

this draft should be abandon, imho.  if kept, it needs serious surgery.

I agree that this draft isn't very useful. It only repeats the guidelines that are already present in various documents with the addition of the requirement that prefixes are /48 or shorter, which doesn't make much sense. The IPv6 unicast address space allows for 2^45 /48s, and there is no way interdomain routing is going to scale with 35184372088832 routes. So if we're only going to carry a subset of the full set of /48 routes, there is no reason to set a hard boundary at /48. And in section 2.6, RFC 3513 states that for some anycast addresses, "the anycast address must be maintained as a separate routing entry throughout the entire internet". So that would be a /128.
_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]