Re: IPv6 news
but when similar things were proposed at other meetings, somebody always said no! we have to have end- to-end, and if we'd wanted nat-around-every-net we'd've stuck with IPv4. Is VJ compression considered a violation of the end-to-end principle? Or perhaps I misunderstand (yet again). Paul is correct. Things that looked like NAT were rejected because NAT is evil. Shifting the NAT to end system removed the objection to NAT, tho it's not entirely clear why. Shifting NAT to the end system also happened to simplify the entire solution as well. VJ compression should not be considered a violation of the end-to- end principle, as it is a per-link hack and performs a function that CANNOT be performed in the end systems. However, I'm not entirely sure that this is relevant. NAT is not, strictly speaking, a violation of the end-to-end principle. It certainly is rather ugly and awkward from an architectural perspective, but it is a function that is not otherwise required in the end host, so placing it into the network does not violate the letter of the principle. Perhaps this is yet another case where people misunderstand the principle itself and are invoking it to give a name to their (well placed) architectural distaste. Tony
Re: IPv6 news
Hi Tony, On Sat, 15 Oct 2005 23:26:20 -0700 Tony Li [EMAIL PROTECTED] wrote: snip Perhaps this is yet another case where people misunderstand the principle itself and are invoking it to give a name to their (well placed) architectural distaste. Doesn't NAT, or more specifically the most commonly used, NAPT, create hard state within the network, which then makes it violate the end-to-end argument ? Also, because it has to understand transport and application layer protocols, to be able to translate embedded addresses, doesn't this also make it violate end-to-end ? I've understood the fundamental benefit of following the end-to-end argument is that you end up with a application agnostic network, which therefore doesn't create future constraints on which applications can then be used over that network. In an end-to-end compliant network, any new transport layer protocols, such as SCTP or DCCP, and new user applications, only require an upgrade of the end or edge node software, which can be performed in an incremental, per edge node as needed basis. In other words, there isn't any whole of network upgrade cost or functionality deployment delay to support new applications, which was the drawback of application specific networks, such as the traditional POTS network. Have I somehow misunderstood the intent or benefits of the end-to-end argument ? Thanks, Mark. -- The Internet's nature is peer to peer.
And Now for Something Completely Different (was Re: IPv6 news)
Tony, On Oct 15, 2005, at 11:26 PM, Tony Li wrote: Paul is correct. Things that looked like NAT were rejected because NAT is evil. Religion is so much fun. Shifting the NAT to end system removed the objection to NAT, tho it's not entirely clear why. Shifting NAT to the end system also happened to simplify the entire solution as well. Except for the part about having to rewrite all existing implementations to take full advantage of the technology. VJ compression should not be considered a violation of the end-to- end principle, as it is a per-link hack and performs a function that CANNOT be performed in the end systems. However, I'm not entirely sure that this is relevant. Well, if you NAT the destination identifier into a routing locator when a packet traverses the source edge/core boundary and NAT the locator back into the original destination identifier when you get to the core/destination edge boundary, it might be relevant. The advantages I see of such an approach would be: - no need to modify existing IPv6 stacks in any way - identifiers do not need to be assigned according to network topology (they could, in fact, be allocated according to national political boundaries, geographic boundaries, or randomly for that matter). They wouldn't even necessarily have to be IPv6 addresses just so long as they could be mapped and unmapped into the appropriate locators (e.g., they could even be, oh say, IPv4 addresses). - locators could change arbitrarily without affecting end-to-end sessions in any way - the core/destination edge NAT could have arbitrarily many locators associated with it - the source edge/core NAT could determine which of the locators associated with a destination it wanted to use Of course, the locator/identifier mapping is where things might get a bit complicated. What would be needed would be a globally distributed lookup technology that could take in an identifier and return one or more locators. It would have to be very fast since the mapping would be occurring for every packet, implying a need for caching and some mechanism to insure cache coherency, perhaps something as simple as a cache entry time to live if you make the assumption that the mappings either don't change very frequently and/ or stale mappings could be dealt with. You'd also probably want some way to verify that the mappings weren't mucked with by miscreants. This sounds strangely familiar... Obviously, some of the disadvantages of such an approach would be that it would require both ends to play and end users wouldn't be able to traceroute. I'm sure there are many other disadvantages as well. However, if an approach like this would be technically feasible (and I'm not entirely sure it would be), I suspect it would get deployed _much_ faster than an approach that requires every network stack to be modified. Again. Particularly given the number of folks who care about multi-homing are so small relative to the number of folks on the Internet. Can two evils make a good? :-) Rgds, -drc (speaking only for myself, of course)
Re: IPv6 news
On Sun, 16 Oct 2005, Christopher L. Morrow wrote: I don't want to speak for Daniel, nor other operators really, but a solution that doesn't allow an operator to traffic engineer internally or externally is just not workable. For the same reasons quoted in your other messages to me: Increased reliance on the Internet Well, people havn't been at all keen on solutions which would need fairly significant changes to how the operators do inter-AS routing (even if they would avoid shifting some aspects of routing to end-nodes). Given this high-resistance (rightly, wrongly, doesn't matter) to big changes in the transit parts of the internet, the only place then to do it is at the edges: have leaf-sites^Wnodes be more far active in how their packets are routed (by making deliberate use of the current provider aligned allocation-topology transit internet). What kind of operator are you thinking of btw? End-node shouldn't bother operators of ISPs really (they'll only get the traffic that the end-node decided it wanted to send via them, which is exactly what you have today ;) ). It could bother operators of other kinds of sites though - but I'm hopeful though that the shim6 mechanisms will be malleable to site-multihoming, even if initially shim6 only concerns itself with end-hosts. If the network isn't reliable due to suboptimal routing issues it can't survive :( Just cause one network is unreliable does not mean that all the networks the end-node is connected to are unreliable. The end-node can try figure out which work and which don't and route accordingly. That's the whole point of shim6 ;). regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: I do not fear computers. I fear the lack of them. -- Isaac Asimov
Re: And Now for Something Completely Different (was Re: IPv6 news)
Hi David, snip Well, if you NAT the destination identifier into a routing locator when a packet traverses the source edge/core boundary and NAT the locator back into the original destination identifier when you get to the core/destination edge boundary, it might be relevant. The advantages I see of such an approach would be: - no need to modify existing IPv6 stacks in any way - identifiers do not need to be assigned according to network topology (they could, in fact, be allocated according to national political boundaries, geographic boundaries, or randomly for that matter). They wouldn't even necessarily have to be IPv6 addresses just so long as they could be mapped and unmapped into the appropriate locators (e.g., they could even be, oh say, IPv4 addresses). - locators could change arbitrarily without affecting end-to-end sessions in any way - the core/destination edge NAT could have arbitrarily many locators associated with it - the source edge/core NAT could determine which of the locators associated with a destination it wanted to use Of course, the locator/identifier mapping is where things might get a bit complicated. What would be needed would be a globally distributed lookup technology that could take in an identifier and return one or more locators. It would have to be very fast since the mapping would be occurring for every packet, implying a need for caching and some mechanism to insure cache coherency, perhaps something as simple as a cache entry time to live if you make the assumption that the mappings either don't change very frequently and/ or stale mappings could be dealt with. You'd also probably want some way to verify that the mappings weren't mucked with by miscreants. This sounds strangely familiar... Certainly does. Apparently this or a similar idea was suggested back in 1997, and is the root origin of the 64 bits for host address space, according to Christian Huitema, in his IPv6 book - http://www.huitema.net/ipv6.asp. A google search found the draft : GSE - An Alternate Addressing Architecture for IPv6 M. O'Dell, INTERNET DRAFT, 1997 http://www.caida.org/outreach/bib/networking/entries/odell97GSE.xml Can two evils make a good? :-) Not sure, however, two wrongs don't make a right, but three lefts do. Regards, Mark. -- The Internet's nature is peer to peer.
Re: And Now for Something Completely Different (was Re: IPv6 news)
Shifting the NAT to end system removed the objection to NAT, tho it's not entirely clear why. Shifting NAT to the end system also happened to simplify the entire solution as well. Except for the part about having to rewrite all existing implementations to take full advantage of the technology. That was inevitable from the start. A real locator/identifier separation requires a rewrite. Any system that provided site-wide source address control was going to require a rewrite. The bigger issue is that given that rewrite was inevitable, why didn't we have more design freedom. Religion *is* so much fun. Obviously, some of the disadvantages of such an approach would be that it would require both ends to play and end users wouldn't be able to traceroute. I'm sure there are many other disadvantages as well. However, if an approach like this would be technically feasible (and I'm not entirely sure it would be), I suspect it would get deployed _much_ faster than an approach that requires every network stack to be modified. Again. Particularly given the number of folks who care about multi-homing are so small relative to the number of folks on the Internet. David, I should point out that if only a small number of folks care about multihoming, then only a small number of folks need to change their stacks. And even in your solution, there would need to be some changes to the end host if you want to support exit point selection, or carry alternate locators in the transport. It's just a mess. I think that we all can agree that a real locator/ identifier split is the correct architectural direction, but that's simply not politically tractable. If the real message that the provider community is trying to send is that they want this, and not IPv6 as it stands today, then that's the message that should be sent, without reference to shim6. Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
Certainly does. Apparently this or a similar idea was suggested back in 1997, and is the root origin of the 64 bits for host address space, according to Christian Huitema, in his IPv6 book - http://www.huitema.net/ipv6.asp. A google search found the draft : GSE - An Alternate Addressing Architecture for IPv6 M. O'Dell, INTERNET DRAFT, 1997 http://www.caida.org/outreach/bib/networking/entries/odell97GSE.xml Note that GSE is in no way a NAT, so is very different than David's proposal. GSE also has a direct impact on all implementations (e.g., only use the identifier bits in the TCP pseudo-header, so that is also an all- implementations change. Further, that is a flag day, worldwide, even for non-multi-homed sites. Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
Tony Li wrote: It's just a mess. I think that we all can agree that a real locator/ identifier split is the correct architectural direction, but that's simply not politically tractable. If the real message that the provider community is trying to send is that they want this, and not IPv6 as it stands today, then that's the message that should be sent, without reference to shim6. Tony How is a split between locator / identifier any different logicaly from the existing ipv4 source routing? I thought that got dead ended? Or is a table lookup going to be needed? Wont all those tables need to be in the exact (or close to) same place as the current routing tables? Appreciate any enlightenment. Joe
Re: IPv6 news
Doesn't NAT, or more specifically the most commonly used, NAPT, create hard state within the network, which then makes it violate the end-to-end argument ? Also, because it has to understand transport and application layer protocols, to be able to translate embedded addresses, doesn't this also make it violate end-to-end ? I've understood the fundamental benefit of following the end-to-end argument is that you end up with a application agnostic network, which therefore doesn't create future constraints on which applications can then be used over that network. In an end-to-end compliant network, any new transport layer protocols, such as SCTP or DCCP, and new user applications, only require an upgrade of the end or edge node software, which can be performed in an incremental, per edge node as needed basis. In other words, there isn't any whole of network upgrade cost or functionality deployment delay to support new applications, which was the drawback of application specific networks, such as the traditional POTS network. Have I somehow misunderstood the intent or benefits of the end-to-end argument ? Mark, This is probably the most common misunderstanding of the end-to-end principle out there. Someone else can dig up the quote, but basically, the principle says that the network should not replicate functionality that the hosts already have to perform. You have to look at X.25's hop-by-hop data windows to truly grok this point. Many people pick this up and twist it into ~the network has to be application agnostic~ and then use this against NATs or firewalls, which is simply a misuse of the principle. Really, this is a separate principle in and of its own right. It's not one that I subscribe to, but that's a different conversation... Regards, Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
How is a split between locator / identifier any different logicaly from the existing ipv4 source routing? IPv4 source routing, as it exists today, is an extremely limited mechanism for specifying waypoints along the path to the destination. This is completely orthogonal to a real identifier/locator split, which would divide what we know of as the 'address' into two separate spaces, one which says where the node is, topologically, and one which says who the node is. One might use the identifier in the TCP pseudo-header, but not the locator, for one example, immediately allowing both mobility and multi-homing. Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Sun, 16 Oct 2005, Joe Maimon wrote: Tony Li wrote: It's just a mess. I think that we all can agree that a real locator/ identifier split is the correct architectural direction, but that's simply not politically tractable. If the real message that the provider community is trying to send is that they want this, and not IPv6 as it stands today, then that's the message that should be sent, without reference to shim6. Tony How is a split between locator / identifier any different logicaly from the existing ipv4 source routing? I thought that got dead ended? Or is a table lookup going to be needed? Wont all those tables need to be in the exact (or close to) same place as the current routing tables? Appreciate any enlightenment. For example, if your goal was to have TCP-like sessions between identifiers survive network events without globally propagating full network topology information about your site (the gripe against classic IPv4 BGP) you could have multiple locators associated with any single identifier sort of like the same way you can have multiple A records for a domain name. If the location layer session times out then it would try the other locators listed (pick a method of selection) and if it suceeded would resume the session transparent to the identifier layer. Design the timeout and retransmit algorithm and parameters to achieve the convergence times of your choice. You would need a new protocol stack on the hosts at both ends of connections. By common convention classic TCP hosts could be told to use one of the locators (a transition hack, or just run the protocols in parallel). No change would be required to the network, and existing TCP could continue to be supported (no flag day). Of course support of this new protocol would be limited to the clients and servers that chose to implement it, however this is no less than the change required for IPv6 which some hoped would solve the multihoming problem (possibly defined as scalably supporting network topology change without sessions being interrupted). Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: And Now for Something Completely Different (was Re: IPv6 news)
Tony Li wrote: How is a split between locator / identifier any different logicaly from the existing ipv4 source routing? IPv4 source routing, as it exists today, is an extremely limited mechanism for specifying waypoints along the path to the destination. IOW the end stations were supposed to be able to tell eachother how to route to eachother. Obviously that does not work in todays internet. But that was a seperation between the endpoints ID and the routing of the packet. This is completely orthogonal to a real identifier/locator split, which would divide what we know of as the 'address' into two separate spaces, one which says where the node is, topologically, and one which says who the node is. One might use the identifier in the TCP pseudo-header, but not the locator, for one example, immediately allowing both mobility and multi-homing. Do you mean adding a second address space to be used by all l3 protocols? Or adding a second address space for every L3 protocol? Or adding a layer 2.5 address space? That appears to be what shim6 is. Also my original question -- How do I send my packet to the other node? I cant just address my packet to the ID, I have to use either information supplied by that node or by a third party. Source routing or routing tables. If this decoupling depends on inband negotiated information, than this allows survivability, but it is not multihoming where multihoming is described as what we do now. Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
Mike Leber wrote: On Sun, 16 Oct 2005, Joe Maimon wrote: For example, if your goal was to have TCP-like sessions between identifiers survive network events without globally propagating full network topology information about your site (the gripe against classic IPv4 BGP) you could have multiple locators associated with any single identifier sort of like the same way you can have multiple A records for a domain name. Real world shows that that doesnt work very well. Multiple A records is not usuable practicaly speaking for anything other than load balancing, today. If the location layer session times out then it would try the other locators listed (pick a method of selection) and if it suceeded would resume the session transparent to the identifier layer. Design the timeout and retransmit algorithm and parameters to achieve the convergence times of your choice. DNS is a good example of something that was designed that way, but few people rely on common implementations actualy performing it properly. You would need a new protocol stack on the hosts at both ends of connections. By common convention classic TCP hosts could be told to use one of the locators (a transition hack, or just run the protocols in parallel). No change would be required to the network, and existing TCP could continue to be supported (no flag day). Appears to me thats what shim6 is (cursory reading + nanog discussions) Of course support of this new protocol would be limited to the clients and servers that chose to implement it, however this is no less than the change required for IPv6 which some hoped would solve the multihoming problem (possibly defined as scalably supporting network topology change without sessions being interrupted). Long story short, seperating endpoint/locator does nothing to allow multiple paths to a single IP6 address/prefix to scale.
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Sun, 16 Oct 2005, Joe Maimon wrote: Mike Leber wrote: On Sun, 16 Oct 2005, Joe Maimon wrote: For example, if your goal was to have TCP-like sessions between identifiers survive network events without globally propagating full network topology information about your site (the gripe against classic IPv4 BGP) you could have multiple locators associated with any single identifier sort of like the same way you can have multiple A records for a domain name. Real world shows that that doesnt work very well. Multiple A records is not usuable practicaly speaking for anything other than load balancing, today. You are missing the point. Currently multihomed sites have multiple path entries in the routing table for a specific multihomed prefix. Instead of having multiple paths, you would have multiple location records in DNS. (Which are A records and any possible reordering by round robbin is not part of the actual path selection algorithm and which are associated with indentifiers though a standard to be designed as part of the new protocol.) The process of how you select which one to use (and what knobs you have for tuning) is a design decision, the same way it was with BGP and OSPF. If the location layer session times out then it would try the other locators listed (pick a method of selection) and if it suceeded would resume the session transparent to the identifier layer. Design the timeout and retransmit algorithm and parameters to achieve the convergence times of your choice. DNS is a good example of something that was designed that way, but few people rely on common implementations actualy performing it properly. BGP and OSPF have timeouts and select other paths. They give you the convergence you have now in the event of router failure. For example, a BGP session with a peer accross a public exchange has to time out, your interface is still up. Yes, you have to engineer the protocol for the convergence time you want. Define the goal and figure out the algorithm to achieve it. You would need a new protocol stack on the hosts at both ends of connections. By common convention classic TCP hosts could be told to use one of the locators (a transition hack, or just run the protocols in parallel). No change would be required to the network, and existing TCP could continue to be supported (no flag day). Appears to me thats what shim6 is (cursory reading + nanog discussions) Perhaps a shim6 advocate will explain the differences. Does shim6 provide separate identifiers from locators? Does shim6 require new protocol stacks on the hosts at both ends of a session? (If not then the source is not making its own path selection decisions.) Of course support of this new protocol would be limited to the clients and servers that chose to implement it, however this is no less than the change required for IPv6 which some hoped would solve the multihoming problem (possibly defined as scalably supporting network topology change without sessions being interrupted). Long story short, seperating endpoint/locator does nothing to allow multiple paths to a single IP6 address/prefix to scale. Um, this is equivalent to saying it doesn't work because I say so. How doesn't it work? For example you could claim (and then try to defend your claim): * It can't possibly converge quick enough because the genius that went into BGP and OSPF was lost and can never be found again. * (ok seriously) It can't converge quick enough because the timeout would have to be X and based on a guestimate of network topology entropy that would result in Y percent more traffic as each host tries to reestablish locator sessions. (Well, then define what percentage of sessions you think get interruped and support your claim.) * You throw away real topology information and rely on latency (or whatever), and using latency doesn't work because it doesn't allow traffic engineering according to policy. (Who said you have to give everybody the same set of locators? Paul might say e. FWIW, if you want the ability to tell different peers different answers like with BGP you will need the ability to give different answers with the new protocol.) Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Sun, 16 Oct 2005, Mike Leber wrote: Does shim6 require new protocol stacks on the hosts at both ends of a session? (If not then the source is not making its own path selection decisions.) As I understood it, shim6 is a way for two hosts to communicate between each other that they have multiple IPv6 addresses. So if a timeout occurs to the last used address, you can try another and try to resume the communication. So if the web-server has two different IP:s (from two different providers), both would be in DNS (preferrably) and the TCP session would be established with one of them. If shim6 detects that the original path is broken, it will try to use another and if it succeeds, the application won't notice anything as shim6 will abstract this to the TCP layer. I think this is a really good idea, having the network know about all multihomed companies just doesn't scale. With less prefixes and less AS numbers, network convergance would be much better. Think in the future, do we really want routers that'll handle millions of prefixes and hundreds of thousands of AS numbers, just because people want resiliance? If this can be solved on the end-user layer instead, it's more scalable. I can also see a loadbalancing scheme coming out on top of shim6 that'll be usable to end users as well. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: And Now for Something Completely Different (was Re: IPv6 news)
Think in the future, do we really want routers that'll handle millions of prefixes and hundreds of thousands of AS numbers, just because people want resiliance? Something will have to provide it and I don't want it to be each of my hosts. I'd rather the hundreds of hosts handle payload and a few proper network devices handle where to move it If this can be solved on the end-user layer instead, it's more scalable. Sadly most end users will have no idea and cause more trouble that it's worth if hosts do it brandon
RE: IPv6 news
The problem with that (and many premises) is that we need to remember these arguments and foreseen problems were all dreamed up 10 or so years ago. The status of everyone's network, everyone's business needs and everyone's network design (and capabilities) were drastically different that long ago. It's a solution that made sense for far different reasons when it was created then it makes sense for now. *shrug* Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Vixie Sent: Sunday, October 16, 2005 12:08 AM To: nanog@merit.edu Subject: Re: IPv6 news [EMAIL PROTECTED] (David Conrad) writes: On Oct 15, 2005, at 3:27 PM, Tony Li wrote: When we explored site multihoming (not rehoming) in the ways that you seem to suggest, it was effectively a set of coordinated NAT boxes around the periphery of the site. That was rejected quite quickly. What were the reasons for rejection? i wasn't there for that meeting. but when similar things were proposed at other meetings, somebody always said no! we have to have end-to-end, and if we'd wanted nat-around-every-net we'd've stuck with IPv4. -- Paul Vixie
Re: Level 3's side of the story
Kevin Loch writes: Does anyone have reachability data for c-root during this episode? The RIPE NCC DNSMON service has some: http://dnsmon.ripe.net/dns-servmon/server/plot?server=c.root-servers.nettype=dropststart=1128246543tstop=1128972253 According to BGPlay for that particular prefix from Route-Views data (for some reason the RIPE RIS server used by BGPlay seems to be down at the moment), the episode seems to be between these times (UTC): 2005-10-05 09:49:03 Route Withdrawal ( 3356 174 2149 ) 2005-10-07 19:24:13 Route Announcement 3356 174 2149 The interval in the URL above starts 72 hours before the start of the episode and ends 72 hours after its end. I cannot see any particular problems that would coincide with the episode, from that set of probes (RIPE TTM). Because we rely on default routes to our three transit providers, and Level(3) is one of them, some of our customers must have had connectivity issues to Cogent for a few hours, until we noticed (thanks to Adam Rothschild and NANOG) and implemented a workaround. But our RIPE TTM boxes (tt85 as well as the currently broken tt86) aren't in those parts of our network. I wonder if they made separate arrangements for that or are planning to make arrangements for phase 2. As someone else said, partial unreachability of a particular root nameserver isn't that much of an issue. But it's an interesting question nevertheless. -- Simon.
Re: And Now for Something Completely Different (was Re: IPv6 news)
Forgot to subscribe to nanog-post first time round... Forwarded Message On Sun, 2005-10-16 at 05:31 -0400, Joe Maimon wrote: Long story short, seperating endpoint/locator does nothing to allow multiple paths to a single IP6 address/prefix to scale. I may be wrong - I haven't been following shim6 for long, but to me it does appear to scale because it is moving the host identity problem from being an IP address that exists in a single long prefix in the core routing table to being an identifier (128 bit number) which maps to a number of existing IP addresses which each already live in much shorter prefixes in the core routing tables. i.e. move the problem from the core to the edge nodes. Those edge node only need to locator lookup tables for the hosts they are talking to - not all that they may talk to. e.g. Say there is a host a::1 and my server has 3 IP addresses b::1, c::1 and d::1, via service providers B, C and D. As it stands, obviously a::1 can talk directly to the server using any of the addresses. Now, say I want to multi-home. Obviously in the past, I would have gotten my own prefix, say e:: and ASN and announced it. But now with shim6, I could use e::1 as the identifier for my host and use b::1, c::1 and d::1 as the locators. So now someone requests a for my host and gets back e::1. Now when a::1 tries to connect to e::1, the shim does a lookup and sees three possible locators - b::1, c::1 and d::1. It selects one of them and packets are then routed between a::1 and one of b::1, c::1 and d::1 in the same way that they would today. How are there traffic engineering problems when at the end of the day the packets will still be routed in the same way? Or am I missing some crucial point? Regards, John
Re: IPv6 news
# but when similar things were proposed at other meetings, somebody always # said no! we have to have end-to- end, and if we'd wanted # nat-around-every-net we'd've stuck with IPv4. # # Is VJ compression considered a violation of the end-to-end principle? # # Or perhaps I misunderstand (yet again). vj is a framing protocol. IP goes in, IP comes out. univerality is retained.
Re: IPv6 news
there is no hope in having operators explain to ietf that the current path is fruitless? certainly they can be made to see the light, yes? you have not spent much time with the ivtf, have you? Actually Chris has been extremely active in the IETF - his draft on current/desired router filtering capabilities is something that's been needed for a while (draft-morrow-filter-caps-01.)
Re: Deploying 6to4 outbound routes at the border
Daniel Roesen writes: On Fri, Oct 14, 2005 at 10:45:33PM -0400, Todd Vierling wrote: Maybe to start -- but again, what kind of 6to4 traffic level are we expecting yet? Peak or average? Think twice before answering. :-) I'm told there are 6to4 relays seeing in excess of 100mbps. Not bursts. Can you imagine trying to handle 100mbps internet mix traffic process switched? :-Z Not even talking about the peaks. Note that not all Cisco routers use process switching for 6to4 tunnel encap/decap (which is really just IPv6-in-IPv4). Catalyst 6500/7600 OSR with PFC-3 (Sup32/Sup720) do this in hardware. -- Simon.
Re: And Now for Something Completely Different (was Re: IPv6 news)
On 16-Oct-2005, at 03:37, David Conrad wrote: Shifting the NAT to end system removed the objection to NAT, tho it's not entirely clear why. Shifting NAT to the end system also happened to simplify the entire solution as well. Except for the part about having to rewrite all existing implementations to take full advantage of the technology. Thought experiment: how many different software vendors need to change their shipping IPv6 code in order for some new feature like shim6 to be 80% deployed in the server and client communities of hosts? I'm thinking it's probably less than 5, but I'd be interested to hear opinions to the contrary. Joe
Re: IPv6 news
On 16-Oct-2005, at 10:27, John Reilly wrote: On Sat, 2005-10-15 at 22:02 -0700, David Conrad wrote: I _really_ wish people would stop saying 'unlimited' or 'almost infinite' when talking about IPv6 address space. It simply isn't true, even in the theoretical sense, and particularly given how address space is being allocated now. It also gives many people the wrong impression: that IPv6 addresses will mean every grain of sand in the Universe (or whatever) can have portable address space. Am I mistaken in thinking that if shim6 (or something like it) did exist, that portable address space could be allocated to everyone (maybe with a different allocation policy?) to be used as (shim6) identifiers. Yes, you're mistaken. The locator identifier is chosen from the host's pool of upper-layer identifiers. Many people speculating and asking questions in this thread would do very well to take a quick read through this high-level description: http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt Note also (as Susan mentioned) the IAB is facilitating a BOF on IPv6 multi-homing in Los Angeles, for those who are planning to attend. Joe
Re: IPv6 news
# The problem with that (and many premises) is that we need to remember these # arguments and foreseen problems were all dreamed up 10 or so years ago. # The status of everyone's network, everyone's business needs and everyone's # network design (and capabilities) were drastically different that long ago. # # It's a solution that made sense for far different reasons when it was # created then it makes sense for now. nope. the problems we're discussing on this thread were all identified ten years ago but ipv6 got standardized in spite of the warnings. ipv6 as it is now specified never made sense for any network, either existing or possible, and all it's really done is to make a bad situation worse and a hard problem even harder to solve. but by handing /32 sugar pills to early adopters, some momentum will be created, and the folks who will not be able to multihome later on will not by that time have any choice except to accept status quo. it's a neat solution, i wish i'd thought of it. (i was blinded by idealism.)
design of a real routing v. endpoint id seperation
How about something like this.
A chunk of ipv6 space is carved off. This is assigned to multihoming
desiring sites.
All routers {can | should } filter this space from their tables
completely by default - except the single prefix covering the entire space.
A customer with a prefix assigned from this chunk has to connect with an
ISP who has
* a Very Large Multihoming (to handle scaling concerns) router somewhere
in its network that peers to other ISP Very Large Multihoming routes.
ISP operating a VLMrouter to offer multihoming service to their
customers would originate the entire multihoming space prefix to their
customers AND to all their peers.
These would have ALL the prefixes from the Multihoming Space.
* the customer would peer with the VLMrouter, receive no routes and
advertise their prefix.
* source routing allowed on ingres IF the destaddr is in the multihoming
space AND the route-option is the Very Large Multihoming router
* source routing is allowed within the ISP network
The VLMrouter would make a SOURCE routing decision, putting a source
route destination to the customer.
* The ISP allows egress source routed packets
What this means is that there are 2 tables on the internet, the table
that ALL internet routes need have (like today) and the table that only
an ISP offering access to multihoming need have. The ISP offering such
access would only need, say one box per POP or so.
So the scaling problem becomes much smaller in scope. Now only ISP
wishing to offer multihoming services need to track the multihoming
table. Additionaly, the tables are actually halved, the VLMrouter need
not contain the normal internet routes and vice versa.
The downside is that an ISP performing as multihoming table hoster would
be a magnet for traffic that would possibly transit in and out.
Smaller multihoming hosting ISPs would probably try to prepend the
prefix mightily, or arrange not to originate it at all, and simply
receive prefix source routed from an ISP they connect to who also hosts
multihoming hosting AND originates the prefix.
No changes to stacks, endpoint nodes or anything else needed.
(if source routing still works in ip6?)
Some source routing filtering capabilities needed for border patrolling
something like this
config-if#ip source-routing prefix-list multihoming-prefixes
access-group allowed-source-routes
Joe
Re: And Now for Something Completely Different (was Re: IPv6 news)
GSE also has a direct impact on all implementations (e.g., only use the identifier bits in the TCP pseudo-header, so that is also an all- implementations change. Further, that is a flag day, worldwide, even for non-multi-homed sites. a flag day only for the very small number of ipv6 sites pay me now or pay me later randy
Re: IPv6 news
On Sun, 2005-10-16 at 11:08 -0400, Joe Abley wrote: Am I mistaken in thinking that if shim6 (or something like it) did exist, that portable address space could be allocated to everyone (maybe with a different allocation policy?) to be used as (shim6) identifiers. Yes, you're mistaken. The locator identifier is chosen from the host's pool of upper-layer identifiers. Sorry, maybe I wasn't clear when I said identifier - I meant endpoint identity (ULID) not locator. I had read a portion (most of the first 3 sections) of draft-ietf-shim6- arch-00.txt to try and get the main concepts. Just so I get it straight, as I've read it, there are ULIDs (which I mistakenly called identifiers in my previous posts), and there are locators (which are real routable IP addresses). From section 3: There are a number of options in the choice of an endpoint identity realm, including the use of existing addresses as an identity tokens, the use of distinguished (possibly non-routeable) addresses as tokens, or the use of tokens drawn from a different realm (such as use of a fully qualified domain name). Shim6 uses the first of these options, and the endpoint identity for a host is one of the locator addresses that are normally associated with the host. The particular locator address selected to be the endpoint identity (or ULID) is specified in [RFC3484]. Shim6 does not mandate the use of distinguished addresses as identities, although the use non-routeable distinguished addresses in this context is described as an option in this approach. So currently, shim6 will always use a routable IP address (one of the locators) as the ULID, but it seemed to leave the option open for non- routable addresses to be used. Therefore, my conclusion that a portable (but non-routed) address might be used. . And now, after reading the rest of the draft, I see that use of non- routable addresses has only been explored at an abstract level. Obviously the null tranform for ULID-locator wouldn't work when establishing a session if the ULID was non-routable. One comment/question and I know this is probably the wrong forum, but in section 4.1 there is a question What form of token is passed to the IP layer from the upper level protocol element as an identification of the remote session target?. As part of the answer, it says If the initial identification of the remote host is via a domain name, then this approach assumes that there are a one or more locators held in the DNS. Should that not read that there are one or more ULIDs held in DNS? Although in practice, it seems that the set of ULIDs and locators will probably be the same (although not always?) so it probably won't matter much. John
Re: And Now for Something Completely Different (was Re: IPv6 news)
# ... # # Obviously, some of the disadvantages of such an approach would be that it # would require both ends to play and end users wouldn't be able to # traceroute. I'm sure there are many other disadvantages as well. ... ok, so here's the problem. we don't have what the iab thinks of as end-to-end and we have not had it for a long time and it's not coming back under any circumstances. but the people willing to serve on the iab, as filtered down to the set of people willing to be put on the iab by any particular nomcom, do not believe this, or they believe it but they behave like a supreme court nominee who gets an inevitable question about roe-v-wade and their knee jerks and they say i support the constitution. so even though NAT is here to stay and firewalls are here to stay and proxies are here to stay and most ipv6 deployment by the end of its useful lifetime will have used RFC1918-like private addressing, or be behind firewalls that limit flows to what a security administrator can predict and protect and understand... officially the IAB can never, ever recognize this or act on it or make decisions or interpretations or recommendations based on it. that's how politics just is and our proper course is to build and deploy technology that works even if it goes against what the IAB has writ and seems a little bit subversive at the time it comes out (as with firewalls, and NAT), and let the political world play catch-up to the real world that we actually live in. # However, if an approach like this would be technically feasible (and I'm not # entirely sure it would be), I suspect it would get deployed _much_ faster # than an approach that requires every network stack to be modified. Again. # Particularly given the number of folks who care about multi-homing are so # small relative to the number of folks on the Internet. right. # Can two evils make a good? :-) definitely.
Re: And Now for Something Completely Different (was Re: IPv6 news)
# ... # # You are missing the point. # # Currently multihomed sites have multiple path entries in the routing table # for a specific multihomed prefix. # # Instead of having multiple paths, you would have multiple location records # in DNS. (Which are A records and any possible reordering by round robbin is # not part of the actual path selection algorithm and which are associated # with indentifiers though a standard to be designed as part of the new # protocol.) # # The process of how you select which one to use (and what knobs you have for # tuning) is a design decision, the same way it was with BGP and OSPF. yes. we called this the A6/DNAME/SRV approach. # * You throw away real topology information and rely on latency (or # whatever), and using latency doesn't work because it doesn't allow traffic # engineering according to policy. (Who said you have to give everybody the # same set of locators? Paul might say e. ... some applications need best-latency. others, best-isochrony. still others, highest-bandwidth. i don't think the network should have a single policy, but i don't think every application should have to test for latency, isochrony, and bandwidth toward each potential endpoint before it selects one. can't we collect this information as hint state and make it available to applications who will then make their decision privately? or failing that, just use SRV? # FWIW, if you want the ability to tell different peers different answers like # with BGP you will need the ability to give different answers with the new # protocol.) that's how i envision that the NSID option would be used from the client side, though i recognize that this will make ed lewis's head explode, that's OK too.
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Sun, 16 Oct 2005 10:55:38 EDT, Joe Abley said: Thought experiment: how many different software vendors need to change their shipping IPv6 code in order for some new feature like shim6 to be 80% deployed in the server and client communities of hosts? I'm thinking it's probably less than 5, but I'd be interested to hear opinions to the contrary. Client end, if Microsoft, MacOS X, and the various Linuxoids shipped, you'd have pretty good coverage. Maybe Solaris 11 if they're still relevant by then. A few vendor Unixoids (AIX, Irix, etc), and proprietary systems (z/OS), but those vendors will either read the writing on the wall or fade away... Router end, probably same number - Cisco, Juniper, Linksys and a few other SOHO-class vendors, plus a few I've overlooked. The number is certainly more than 5, very likely close to 1 dozen, unlikely to be more than 2 dozen. Of course, even if everybody shipped a *working* *interoperable* product today (quit giggling - we're being hypothetical here), you'd still have a 3-5 year timeframe before all the stuff sold yesterday and years previous got upgraded or replaced. pgpYMQVSiuBH0.pgp Description: PGP signature
Re: Deploying 6to4 outbound routes at the border
On Sun, 16 Oct 2005, Simon Leinen wrote: Note that not all Cisco routers use process switching for 6to4 tunnel encap/decap (which is really just IPv6-in-IPv4). Catalyst 6500/7600 OSR with PFC-3 (Sup32/Sup720) do this in hardware. And for dual-stack organizations using these at the borders, deploying a local-only 6to4 outbound relay should be easy, right? (The fact that transits should really be providing 6to4 to their downstreams notwithstanding -- it would be faster at the org's border, but if transits collectively offered 2002::/16 as standard practice, it may not be such a big deal.) -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: And Now for Something Completely Different (was Re: IPv6 news)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16-Oct-2005, at 16:20, [EMAIL PROTECTED] wrote: On Sun, 16 Oct 2005 10:55:38 EDT, Joe Abley said: Thought experiment: how many different software vendors need to change their shipping IPv6 code in order for some new feature like shim6 to be 80% deployed in the server and client communities of hosts? I'm thinking it's probably less than 5, but I'd be interested to hear opinions to the contrary. Client end, if Microsoft, MacOS X, and the various Linuxoids shipped, you'd have pretty good coverage. Maybe Solaris 11 if they're still relevant by then. A few vendor Unixoids (AIX, Irix, etc), and proprietary systems (z/ OS), but those vendors will either read the writing on the wall or fade away... To get 80%, I think on the client side you just need support in Microsoft v6-capable operating systems. Router end, probably same number - Cisco, Juniper, Linksys and a few other SOHO-class vendors, plus a few I've overlooked. I don't think you need any support at all on routers for shim6 to be functional for services that users and content providers care about. On the server side, windows plus Solaris plus linux seems like it might give 80%. So, that makes windows, Solaris and Linux. Whether the answer is three, five or twelve, the point I was attempting to make was that it's not necessarily a huge deployment obstacle to roll out shim6 across a good proportion of the network's hosts from the coding point of view. Since no flag day is required, this does not seem necessarily unmanageable. Of course, even if everybody shipped a *working* *interoperable* product today (quit giggling - we're being hypothetical here), you'd still have a 3-5 year timeframe before all the stuff sold yesterday and years previous got upgraded or replaced. Sure. In some ways it's fortunate that Microsoft has yet to ship an operating system where v6 is turned on by default (right? I heard that Vista will be the first?) On the server side there's the additional upgrade carrot that upgrades will facilitate multi-homing, which may make for an easier sale. Anyway. Thought experiment. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDUs2a/f+PWOTbRPIRAsBUAJ0XSgeNfOsVJDt5kOyb0YReiwYnowCgxGCK yb5mI6ijhwUFKTwrZ2OSQyw= =F648 -END PGP SIGNATURE-
Re: IPv6 news
On 16-Oct-2005, at 11:08, Joe Abley wrote: Yes, you're mistaken. The locator identifier is chosen from the host's pool of upper-layer identifiers. Oops -- I meant the upper-layer identifier is chosen from the host's pool of locators. Must Not Post Before Coffee. Joe
Re: IPv6 news
there would seem to be two paths here. the one we are currently walking has more and more complexity to try to deal with the lack of reality-based design in v6. every step, instead of making things simpler, adds more complexity to deal with the mistakes of old narrow decisions. consider an alternative. v6 is barely deployed at all, maybe 1/(10^6) of what it will be. so, a change that seems very expensive now will be trivially amortized if it saves later, while a cost that increases in time (shim6, 6to4, ...) will cost us massively in the future. so, if we had a free hand and ignored the dogmas, what would we change about the v6 architecture to make it really deployable and scalable and have compatibility with and a transition path from v4 without massive kludging, complexity, and long term cost? you can pay me now or pay me later. but later, everything costs a million times as much. randy
IPv6 daydreams
--- Randy Bush [EMAIL PROTECTED] wrote: so, if we had a free hand and ignored the dogmas, what would we change about the v6 architecture to make it really deployable and scalable and have compatibility with and a transition path from v4 without massive kludging, complexity, and long term cost? Okay, I'll bite - If I were king, here's what I'd want to see: I'd change the allocation approach: rather than give every customer a /64, which represents an IPv4 universe full of IPv4 universes, I'd think that any customer can make do with a single IPv4-size universe, and make the default end-customer allocation a /96. ISPs could still get gigantic prefixes (like a /23 or something), to make sure that an ISP would never need more than one prefix. I'd move us to the 1-prefix-per-ASN approach as much as possible - reserve a single /16 for multihoming end-sites, and let that be a swamp. There are under 32K multihomed ASNs in use now, and while demand is growing, if we can keep organizations to one prefix each, the routing table stays pretty darn small. Designate a /96 as private space for use on devices which don't connect to the Internetv6. To qualify for an ISP allocation, an entity would have to agree to route the swamp space, and not route the private space. And as long as I'm dreaming, I'd like a pony... -David Barak- -Fully RFC 1925 Compliant- __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
Re: IPv6 news
On Sat, 15 Oct 2005, Tony Li wrote: I don't want to speak for Daniel, nor other operators really, but a solution that doesn't allow an operator to traffic engineer internally or externally is just not workable. For the same reasons quoted in your other messages to me: Increased reliance on the Internet There's nothing in any multi-prefix multihoming solution that prevents an operator from internal or external traffic engineering. There just isn't a single explicit prefix to manipulate. If, within any given routing domain, you choose to carry a longer prefix and manipulate it to whatever extent your vendor's BGP permits, you and your consenting adult peers are free to do so. Do not, however, expect the rest of us to carry your traffic engineering prefixes. We are not interested. I'm aware that routing table bloat is a problem, I'm also aware that just doing what we do today tomorrow will probably cause lots of expense, failure, or pain at some point in the future. I can't see that source/dest pairs being basically meaningless and large sinks or sources of traffic being anonymous is going to help either. (shim6 provides the possibility for end nodes to 'renumber' and change their source/dest at will, potentially playing havoc with traffic patterns, potentially even inducing 'failure' in the network interconnects along the way. agreed, but it doesn't seem that, until recently atleast, there was much operator participation. Hopefully that's changing for the better :) Hopefully, that will reach a point where the operators show up and participate at IETF, rather than the IETF coming to NANOG. agreed.
Re: IPv6 news
On Sun, 16 Oct 2005, Susan Harris wrote: there is no hope in having operators explain to ietf that the current path is fruitless? certainly they can be made to see the light, yes? you have not spent much time with the ivtf, have you? Actually Chris has been extremely active in the IETF - his draft on current/desired router filtering capabilities is something that's been needed for a while (draft-morrow-filter-caps-01.) doh, supposedly it's a WG document now, but honestly I just have a big mouth, George Jones provided most of the content and guidance... I just tried to hang myself with the xml authoring 'tools' :( I do hope to gain more ietf experience though... (I may bring a hard hat this time around)
Re: IPv6 daydreams
Okay, I'll bite - If I were king, here's what I'd want to see: [ changes to current policies, not architecture, elided ] let's first agree on some goals o really big address space, not the v6 fixed 32 bit limited game. (old dogs will now bay for variable length, aroo!) o a routing system which has the ability to scale really well in the presence of fewer and fewer nodes (think sites) where out-degree == 1 o mobility o really scalable v4 backward compatibility so that we don't have the end-user-affecting mess which looms in a few years anything else? randy
Re: IPv6 daydreams
o really big address space, not the v6 fixed 32 bit s/32/64/ sorry
Re: IPv6 daydreams
On Sun, Oct 16, 2005 at 05:20:12PM -1000, Randy Bush wrote: Okay, I'll bite - If I were king, here's what I'd want to see: [ changes to current policies, not architecture, elided ] let's first agree on some goals o really big address space, not the v6 fixed 32 bit limited game. (old dogs will now bay for variable length, aroo!) woof! o a routing system which has the ability to scale really well in the presence of fewer and fewer nodes (think sites) where out-degree == 1 sure... maybe. is there the presumption of e2e here? o mobility process mobility? latency tolerent? any distinction btwn individual nodes or whole networks? need clarity here. o really scalable v4 backward compatibility so that we don't have the end-user-affecting mess which looms in a few years well... not so sure about this one. why do we care? anything else? randy
Re: IPv6 daydreams
On 17/10/05, David Barak [EMAIL PROTECTED] wrote: I'd change the allocation approach: rather than give every customer a /64, which represents an IPv4 universe full of IPv4 universes, I'd think that any customer can make do with a single IPv4-size universe, and make the default end-customer allocation a /96. I personally am in favor of reducing minimum allocations like this - and as was discussed quite extensively in the botnet of toasters and microwave ovens when you ipv6 enable the lot thread a few weeks back, it usually ends up that there's just one host in a /48 or /64 so that the sparsely populated v6 address space means bots cant go scanning IP space for vulnerable hosts like they do in v4 It also means that when Vint Cerf's research about extending the internet into outer space comes through (or when we finally start exchanging email, http or whatever traffic with aliens), there's sooner or later going to be an intergalactic assembly of some sort where delegations from Betelgeuse and Magrathea will complain about how those @^$^$#^$^ earthlings hogged all the v6 space thinking there's more than enough v6 IP space to allot a /48 to every single molecule on earth, so now they're not getting enough IP space to network a group of computers that'll plot the answer to life, the universe and everything. Well, I know that sounds silly, but people were handing out class A, B and C space for years thinking nobody at all would run out of v4 space, there's lots of it so why not just parcel it out with open hands. Back to operations - there was this interesting proposal - well, two proposals as it turned out - at apnic 20 - http://www.apnic.net/meetings/20/report.html * prop-031-v001: Proposal to amend APNIC IPv6 assignment and utilisation requirement policy o During the discussions, the proposer agreed to a request to separate into two proposals: + Proposal part 1: Evaluation for subsequent allocations to be based on an HD-Ratio value of 0.94 # The proposal reached consensus at the Policy SIG meeting and AMM and has now been referred to the sig-policy mailing list for the next stage in the policy development process. + Proposal part 2: Add a /56 end-site allocation point (in addition to /64 and /48) and default end-site allocation for SOHO end site to be a /56 # This proposal did not reach consensus at the Policy SIG meeting. --srs
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Sun, 16 Oct 2005, Mikael Abrahamsson wrote: Think in the future, do we really want routers that'll handle millions of prefixes and hundreds of thousands of AS numbers, just because people want resiliance? If this can be solved on the end-user layer instead, it's more you are getting these anyway, thank network convergence for that... or curse it, your call. things like 2547 'vpn' and the like are driving prefix numbers up regardless of what the Internet is doing. Hardware will be required to handle million(s) of prefixes sooner than large scale v6 deployment IMHO. Note, just cause it's there (or will be) doesn't mean I'm advocating that solution for v6, I just had questions (and thought others might as well) about shim6 or the direction of 'site multihoming' in v6... (not even specificly shim6)
Re: IPv6 daydreams
o a routing system which has the ability to scale really well in the presence of fewer and fewer nodes (think sites) where out-degree == 1 sure... maybe. is there the presumption of e2e here? i think so, for various valies of e2e o mobility process mobility? latency tolerent? any distinction btwn individual nodes or whole networks? need clarity here. i think the user is gonna expect application binding mobility o really scalable v4 backward compatibility so that we don't have the end-user-affecting mess which looms in a few years well... not so sure about this one. why do we care? becuse isps have these folk called users who pay us money to see that they get the full internet (and let's not go down the silly rat hole of cogent vs level(3), thank you). randy
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Mon, 17 Oct 2005, Christopher L. Morrow wrote: you are getting these anyway, thank network convergence for that... or curse it, your call. things like 2547 'vpn' and the like are driving prefix numbers up regardless of what the Internet is doing. Hardware will be required to handle million(s) of prefixes sooner than large scale v6 deployment IMHO. Both MPLS and any tunneled VPN over IP means the core won't have to know about all those prefixes (think aggregation of addresses regionally in the IP case and outer label in the MPLS case). So if you're building a 100G capable platform that'll do IPv6 and MPLS, how much difference would it be if you only had to support 16000 labels and 16000 IPv6 prefixes, rather than 2 million? Then of course I guess the argument can be made to put everything on MPLS to avoid the core knowing about anything but outer labels. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Mon, 17 Oct 2005, Mikael Abrahamsson wrote: On Mon, 17 Oct 2005, Christopher L. Morrow wrote: you are getting these anyway, thank network convergence for that... or curse it, your call. things like 2547 'vpn' and the like are driving prefix numbers up regardless of what the Internet is doing. Hardware will be required to handle million(s) of prefixes sooner than large scale v6 deployment IMHO. Both MPLS and any tunneled VPN over IP means the core won't have to know about all those prefixes (think aggregation of addresses regionally in the IP case and outer label in the MPLS case). 'core' doesn't matter so much, somewhere there has to be this knowledge... Perhaps you'll get lucky with some 'edge' devices not having to know about every destination, but I think that might be more rare than you'd like. So if you're building a 100G capable platform that'll do IPv6 and MPLS, how much difference would it be if you only had to support 16000 labels and 16000 IPv6 prefixes, rather than 2 million? not sure, I'm a chemical engineer :) Seriously though, is the break 1-2M or is it 10-20m? (doubling or orders of magnitude?) Then of course I guess the argument can be made to put everything on MPLS to avoid the core knowing about anything but outer labels. oh yes, mpls everywhere! wait... did I say that? yuck.
