In message <[email protected]>, Owen DeLong writes: > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum <[email protected]> wrote: > > > Let me address a few points that were brought up by different people. > > > > Renumbering: > > > > We had great plans for making renumbering easy in the early days of IPv6. > > Remember A6 records and bit > labels in the DNS? But none of that went anywhere. The problem isn't so much > that we can't push a prefi > x down the network or update the DNS (although both of these still have > challenges associated with them > ), but that addresses tend to get hardcoded all over the place, starting with > firewalls all the way up > to homegrown applications. I don't think renumbering addresses this issue, > although it could help steer > some smaller organizations away from PI. > > They never went anywhere because they focused on solving the easy part of the > renumbering problem while > utterly and completely ignoring the hard part. > > Easy part: Changing your stuff. > Hard part: Updating all of the prefix lists, filters, firewall rules, VPN > configurations, and other con > figuration elements in systems not under your control that contain your > prefixes (partner VPNs, peer ro > uters, etc.).
Owen this a collective response to the list. Not all that hard at all. Just send signed update requests. I did that with email over a decade ago. You just have to have something listening for them that verifies the signature and updates the system. Write a draft "Remote Firewall Update Request Protocol" and submit it. The alternative is stop worrying about the remote address and use security at the application layer. Or complain to your vendor that you can't use a hostname in the configuration file element. In many cases it doesn't require anything more than looking up a address in the DNS before the operation. Yes, I need to fix the masters clause in named to support this. We already do something similar for NOTIFY messages so it is possible to do this. For masters clauses there is a bootstrap problem to deal with but it is not impossible. Just sending periodic NOTIFY messages will work. Named has had support to do this for 1 1/2 decades now to allow for a a stealth master behind a dial on demand link. It would send a notify periodically. That would bring up the line. The slave would refresh and transfer if required. When that was complete the idle timer on link would drop it. This just used standard signalling designed by the IETF in a different way. Stop expecting someone else to *find* and fix these issues for you. You know what the issues are. Ask your vendors to fix them. If they need to co-ordinate they should know where to go to do it. Mark > NONE of the things proposed in those days did anything at all to address the > hard part. > > > A prefix length limit for the IPv6 DFZ: > > > > Someone mentioned that this didn't work in IPv6. When Sprint decided to > > make that /18, that didn't re > ally work. But there's a de facto /24 limit that everyone understands. With > IPv6, that would translate > into a /48. Obviously no router can hold 2^48 or 2^45 prefixes, so as a > backstop against accidental/mal > icious IPv6 routing table explosion this doesn't help. Even exploding a /28 > or so into individual /48s > would kill the IPv6 DFZ. > > > > What COULD work is to have prefix length limits depending on the allocation > > size by the RIRs. Somethi > ng like: > > > > 2100::/16 -> /48 > > 2200::/16 -> /32 > > 2200::/15 -> /29 > > Because the 4.3 billion routes in the first category won't be a problem > somehow? > > Also, 2200::/16 and 2200::/15 overlap. Did you mean 2300::/16? If I apply > longest match rule to what yo > u've put above, that's the effective result. If you meant something else, I'm > not sure how to divine th > at from what you wrote. > > > However, for this to work well the RIRs would have to group allocations of > > the same size into separat > e blocks, with the result that it would no longer be possible to reserve > space to grow an allocation. ( > Things like allocating a /48 but reserving a /44 reduce the opportunities for > prefix length filtering b > ecause now the strictest filter you can make allows 16 x as many prefixes > worst case than average case. > The worst and average case need to be as close together as possible.) > > I think overall, that would be worse than what we have today. > > > I'd say that allowing two or three extra bits for traffic engineering for > > PA blocks would be good. So > for the part of the IPv6 space where /29s are allocated, allow /31s or /32s. > As traffic engineering in > coming traffic by deaggregation requires that different parts of the > aggregate all generate similar lev > els of incoming traffic, this wouldn't usually work for organizations using > PI so I'd say don't allow d > eaggregating below /48. > > What about multihomed customers? Do you want all multihomed customers to be > forced into getting their s > pace directly from RIRs and not from LIRs? > > There are currently many cases where organizations obtain a /48 (or larger) > from their ISP and subseque > ntly choose to connect to an additional ISP and advertise the PA space as an > independent route through > both ISPs. Many ISPs cooperate in this process and allow this behavior. It > does not change the number o > f routes in the routing table, but it can be less expensive for the customer > if they choose to go that > way. > > Obviously, at their first renumbering event, it makes sense for them to > renumber into PI, but this can > prevent them from having to undergo renumbering while they remain connected > to the initial provider wit > hout actually affecting the global routing table any more than getting PI > would. > > > Geographic communities: > > > > I know this is controversial. "Topology ain't geography". Actually, most of > > the time there is a signi > ficant correlation. If all German cities inject a more specific, do you > really need to hear those in To > kyo or Seattle? Just send the traffic to Europe as per the aggregate and let > them figure it out there. > > Spend much time in Asia or Africa or the Caribbean? > > Sure, in the case of Germany, you probably don't need them in Tokyo or > Seattle. OTOH, if you get a bunc > h of more specifics coming out of Rwanda, it might actually be significant to > have them in Germany, Par > is, and Brussels. > > Where, exactly would you draw these lines and how would you go about handling > the necessary exceptions? > > Europe and the US are rich with exchange points and peering density. The rest > of the world, less so to > varying degrees resulting in more significant differences between topology > and geography, often in ways > that are not necessarily obvious. > > > Compiling a list of communities that identify regions/countries/cities > > would allow for experimentatio > n in this place without any downsides that I can see. Don't like this? Filter > the communities. There's > a handy list that you can copy and paste into your filter. > > For these communities to be useful, they'd have to be transitive and people > would have to agree to appl > y them to their prefixes. What happens in the case of "vigilante" tagging > where some other AS decides t > o start applying these tags to my routes even though I specifically don't > want that? > > > Injecting an aggregate as a point of last resort: > > > > I think this can be done today and probably is done today. But a document > > describing how to do it wou > ld probably be helpful. I'm thinking along the following lines: > > It is already BCP for networks that have the ability to do so. It's not a > separate service or anything, > you just source the aggregate from one or more locations where you have the > ability to forward the tra > ffic as needed. > > > The AoLR (Aggregate of Last Resort) service would entail a service provider > > announcing the aggregate > without necessarily providing connectivity towards all the places announcing > more specifics covered by > the aggregate. So if ISP A announces the AoLR and ISP B provides connectivity > to a more specific, ISP C > would send traffic to A as per the aggregate and then A would immediately > hand it over to B. > > This assumes that A: > 1. Is willing ot accept the more specifics from B. > 2. Is willing to provide (likely unbillable) transit for the > customer in question. > 3. Has a peering relationship with all ISP Bs for the given > customer. > > In my experience, ISPs are usually hesitant to take responsibility for > forwarding traffic they can't bi > ll in some way. > > Item 3 is an even more difficult problem to solve. > > Most organizations, instead of depending on such a service simply build the > necessary tunnels to provid > e their own AoLR capabilities as needed when they don't have internal > circuits for the task. > > > So as part of the AoLR service, a service provider would agree to accept > > all more specifics that fall > under the aggregate (up to an agreed prefix length) from all the networks > providing connectivity towar > ds those more specifics. This would be an attractive service for tier-1s to > provide, because presumably > , they peer with everyone everywhere, so in the case where they receive the > traffic over peering and ne > ed to deliver it to another service provider over peering, this could > probably happen in the same city, > so they wouldn't carry the traffic over long distances. But the > (sub-)organization(s) in question stil > l gets to buy connectivity from a wider range of smaller service providers. > > Tier-1s in my experience not only don't usually peer with everyone > everywhere, they often try to avoid > peering with anyone they consider "beneath them" as a tactic to try and force > those organizations to bu > y services from them. > > Again, I don't see the ISPs wanting to do what you describe since there would > be cost, but little benef > it to them. > > > In practice an organization would contract two or more service providers to > > provide the AoLR service > for redundancy. > > > > Wouldn't they just get PI: > > > > Yes. That's why I think it's important to find a way to give these > > organizations what they need in a > way that keeps the IPv6 DFZ growth on a workable trajectory. > > I think the IPv6 DFZ growth is already on a workable trajectory. If we could > eliminate the massive IPv4 > routing table, then IPv6 is nowhere near outpacing router memory capacity > growth for the foreseeable f > uture. > > The problem is surviving in the interim while we need IPv4 on a global basis. > The reality is that I thi > nk IPv4 routing table bloat is eventually going to be the primary driver for > IPv6 adoption. I think thi > s will occur much faster than most people imagine because I believe that the > fragmentation of the IPv4 > table in the transfer market is going to make IPv4 routing progressively more > untenable until it essent > ially collapses under its own weight. At that point, the remaining laggards > will scramble to deploy IPv > 6 as quickly as possible and the IPv4 table will, largely, evaporate rather > quickly. > > > AS numbers: > > > > BGP assumes that an AS always has internal connectivity. This can be > > accomplished using tunnels, but > it's much better to simply have separate AS numbers for each subunit. Would > it make sense to allocate r > anges of AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers > there's no lack of numbers, an > d this would allow tools to be developed to work on CIDR-like AS number > ranges in the future. > > Yes... I'm all for going back to the definition of an AS as a contiguous > collection of networks with an > identical routing policy. With 32 bits, I think we have enough ASNs to > accomplish this globally. > > Owen > > _______________________________________________ > v6ops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
