Re: IPv6 policy at LACNIC( was: RE: IPv6 Policy Proposal for LACNIC Region
Thomas Narten <narten-r/[email protected]>
| Newsgroups | gmane.org.apnic.global-v6 |
|---|---|
| Message-ID | <[email protected]> |
Brian E Carpenter <[email protected]> writes: > > The intention of the wording "by advertising that connectivity through > > its single aggregated address allocation; and" is to ensure that all > > the addresses covered by the RIR allocation are reachable via a single > > route based on the (single) aggregate allocation. In particular, it > > was intended to ensure that addresses assigned out of that range not > > _require_ multiple longer prefixes be injected into the global routing > > system in order for the idividual sites be reachable. > > > > This does _not_ mean that longer prefixes cannot or should not be > > injected into the routing system. The point is that it should not be > > _required_ that the routing system accept such longer prefixes in > > order to get ubiquitous reachability. > That's a bit hard to reconcile with the firm intention since the beginning > to contain the size of the DFZ for IPv6 by avoiding longer prefixes like > the plague. There is no inconsistency. What is absolutely required is that the number of routing table entries needed to provide basic reachability for _all_ sites on the public internet be reasonably small and manageable. If we cannot do this, then it will not be possible to guarantee reachability for all. It is this requirement that leads to the need to have all end sites reachable through large aggregates. The minimum number of route entries needed to provide connectivity in the DFZ needs to be fairly small. At the same time, it is understood that most ISPs will need to be able to handle and support more than the bare minimum. Perhaps quite a bit more, e.g, double, triple, etc. For example, they will need to be able to maintain more-specific routes for the internal customers. There are market forces at play here that we cannot ignore. At what point the size of a given table/set of prefixes becomes unsustainable is of course the big unknown. What needs to happen here is that ISPs be given the flexibility to adjust the size of their tables in response to individual needs, e.g., by filtering long prefixes if they are unable to carry them, _without_ having such filtering break global reachability for all. So long as all destinations are reachable through the larger aggregates as a sort of last resort, ISPs can freely filter longer prefixes as they see fit. Those that accept the longer prefixes may be able provide better paths (and optimization). When/where to do that can be left to market forces. Thus, it is technically feasible to all longer prefixes be advertised for (say) multihoming support. But this is not a full solution, because there is no guarantee that such prefixes will be accepted everywhere. Consequently, the need to guarantee reachability via the larger aggregates is needed, as at some point in the future, it is quite possible that only the larger aggregates can be propagated throughout the DFZ. > > > Two question, then: > > > 1- Do you think that there is difference among the policy and the proposal > > > because the way it is stated? > > > 2- In case there is no difference, do you think we should also change the > > > policy and remove the requirement of a singla announcement? > > > > The requirement for a single announcement should be there, but it > > should not also imply that longer (more-specific) advertisements are > > not allowed. > But they need to be strongly discouraged. If that is no longer agreed, please > let me know so that we can stop looking for a multihoming solution that > doesn't generate one prefix per site. It certainly needs to be understood that there are limitations with advertising longer prefixes and that they are not guaranteed to be accepted by anyone. Some basic truth-in-advertising is definitely needed here, and that might well translate into discouragement. Thomas _______________________________________________ global-v6 mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/global-v6