Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
valdis.kletni...@vt.edu wrote: Beyond that, if there are multiple routers, having a default router and relying Yes yes we know, and we've understood this for a quarter century or so. My disagreement is that even though 99.8% of machines *don't* have multiple routers, you seem to be pedantically insisting that some sort of IGP is mandatory for *all* end hosts, even though only 0.2% or so will actually see any benefit at all.. Not. Though hosts should implement some IGPs, the default can be to just depend on default routers supplied from DHCP. A better default could be that IGP will be automatically invoked if DHCP does not supply a default router. If there are multiple IGPs are implemented, snooping IGPs' advertisement to know which is the locally available IGP may also be a good idea. My point w.r.t. multiple next hop routers is that RA supplied information is not good enough, which means DHCP is no worse than RA even if there are multiple next hop routers. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 1/11/12 9:58 AM, Masataka Ohta wrote: A better default could be that IGP will be automatically invoked if DHCP does not supply a default router. That's ridiculous. You need some link state to even find a DHCP server. So, the very idea that DHCP would tell you where your routers are is preposterous on its face. Besides, that's terrible system design. You should never design a system where some code paths aren't exercised regularly. If there are multiple IGPs are implemented, snooping IGPs' advertisement to know which is the locally available IGP may also be a good idea. My point w.r.t. multiple next hop routers is that RA supplied information is not good enough, which means DHCP is no worse than RA even if there are multiple next hop routers. I've not read the whole thread yet (I had read the start what seems to be weeks ago), but I'll pipe up here and point out that in my _original_ design, every host was running a link state IGP. Even without any router at all, you need link state to handle mobile nodes, hidden terminals, partitioned networks, satellite versus land-line unidirectional links, etc, etc, etc. Of course, all that was ripped out by the ignorant folks who came later. Thus, IPv6 is much worse at self-configuration, security, mobility, and *everything* than originally envisioned.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Christian Esteve wrote: May be there is some light with Multipath TCP: http://www.ietf.org/proceedings/75/slides/mptcp-0.pdf http://datatracker.ietf.org/wg/mptcp/charter/ Not bad. If you can live without UDP and other issues discussed in this bizarre discussion... UDP connection, if any, by definition, totally depends on users (applications) that handling of multiple addresses must depend on application protocols. A good news is that DNS, the most major application over UDP, supports multiple addresses of name servers from the beginning. Anyway, you can still live with applications over UDP without support for multiple addresses. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Ray Soucy wrote: Well, it seems now you've also added the requirement that we also dramatically re-write all software that makes use of networking. Seemingly for the sake of never admitting that you can be wrong. Thank you for failing to point out where I am wrong. You seem to think that the OSI model is this nice and clean model that cleanly separates everything and that you can just freely replace chunks of it. Not at all. Instead, IPv6 is damaged a lot because of ATM based on so nice and clean OSI model. Again, it's like you live in a theoretical world where physical limitations and operational realities don't exist. A physical limitation and an operational reality is that we can not remember 16B addresses. Go off and write up the RFCs to make this all work, and come back when you have an model implementation we can all look at. As I warned that IPv6, as was, is not operational about ten years ago, it's not my responsibility to try to make IPv6 operational within a decade or two. Instead, I am interested in the fact that IPv4 scales well forever with end to end transparency, if port numbers, which may be 16b, 32b or 48b long, are used for routing. My most recent research result is how to modify client IPv4 stack to achieve end to end transparency for clients behind UPnP capable NAT. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 29 Dec 2011, at 0:16 , Doug Barton wrote: On 12/28/2011 03:13, Iljitsch van Beijnum wrote: However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence. Unless you have a malicious user on the network in which case all traffic immediately switches to the malicious user's gateway. This is a different issue. And although this is / has been common for RAs/stateless autoconfig beceause some idiot at Microsoft made this happen more or less automatically in some configurations, there really is no difference between DHCPv6 and stateless autoconfig here. What I'm talking about is the issue where a legitimate DHCP server gives out an incorrect default gateway addresses because of a configuration mistake. Because a DHCP server that isn't also that same router has no way of knowing that address this can't be automatically done right so mistakes happen. Especially at this point with IPv6 where most people don't notice it when it doesn't work most of the time. I'm aware that SEND is trying to solve this problem, but it's not yet deployed. SEND is similar to IPsec in this regard, it's not going to be deployed widely because it's too complex to do so. I think that people already know of and have solutions for the security issues that exist for DHCP today. Yes, for IPv4. But this is a filtering issue. If you can filter rogue DHCPv6 servers you can also filter rogue RAs. 10-12 years ago I attempted to make 2 points to the IPv6 literati. First that IPv6 would not be widely adopted in the enterprise until it had full DHCP parity with v4. Second that the easiest way to do that would be to declare all existing DHCPv4 options that are relevant to IPv6 as existing in DHCPv6 by fiat, and to prevent new v6-only options from using option numbers that already exist for v4 (and vice versa). I was laughed out of the room on both counts. I agree with you that DHCPv6 doesn't deserve any prizes, not for design, implementation nor time to market. But I disagree that importing all IPv4 cruft into IPv6 for the sake of speeding up deployment that wasn't going to happen anyway would have been a good idea then, let alone now. The good news is that it's not too late to fix DHCPv6. We're at a watershed moment where it's just possible that we'll get the ability to assign a default gateway added to it due to, for lack of a better term, market forces. This would be a major paradigm shift. As you point out the development lead time on stuff like that is rather painful, however if we took advantage of the camel's nose under the tent and included everything relevant that DHCPv4 can do in that update, we'd be in a pretty good condition in a year or so. You are living in a fantasy world if you think that.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Ray Soucy wrote: But that is only the case if you let customers have a PI prefix (which I think is really required in a purist end-to-end model, but for the sake of argument...). Multihoming by routing, by the intermediate systems, is against the end to end principle, which is why it does not scale. The remote host would have no knowledge of other available prefixes As IP layer is connectionless, let transport or application layer carry the information on the prefixes to try to keep connections. (even if there is a path change, and a different path becomes favorable). The remote host can use IGP metric to know the initial best candidate and subsequent path changes. It can be assumed that default free routing table is small. In addition, the remote host may also use transport/application layer timeout to try other prefixes. The result is still a very large amount of overhead. You will still experience significant change propagation delay (slower than change propagation under the current model Not at all. Transport/application timeout is no different. Route propagation is no slower. Instead, smaller default free routing table means more rapid convergence. This all would be significantly more complex than IPv6 It was IPv6 which was expected to support multiple addresses to suppress routing table growth. The result is a complex protocol with halfhearted support for multiple addresses. We now know that it takes well over a decade for people to move to a protocol, even when it is almost operationally identical to its predecessor. Unlike IPv4, IPv6 is poorly operational and still needs protocol modifications, For example, multicast PMTUD causes ICMP implosion, which means rational operators filter ICMP packet too big often including those against unicast packets, which means PMTUD won't work. Yes, fixing it requires more than a decade. Then, it may be a good idea to obsolete SLAAC, which means IPv6 address can be only 8B long. You know, remembering 16B addresses is divine, which is an operational head ache. To be frank, you would have to build a completely new and parallel network and hope you could somehow convince people to adopt it Multihoming with multiple addresses works at transport/application layer over existing IPv4 and IPv6. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Well, it seems now you've also added the requirement that we also dramatically re-write all software that makes use of networking. Seemingly for the sake of never admitting that you can be wrong. You seem to think that the OSI model is this nice and clean model that cleanly separates everything and that you can just freely replace chunks of it. That was the idea; but in practice, there is a lot more grey area, and dependencies. Again, it's like you live in a theoretical world where physical limitations and operational realities don't exist. Honestly. Here is a thought: Go off and write up the RFCs to make this all work, and come back when you have an model implementation we can all look at. I think that would be a win-win for everyone. I normally don't try to dismiss people completely, but you're exhausting. You never directly respond to anything except with a one line assertion like not at all, or by changing the parameters of the argument to a model that doesn't exist. I could do that too: It can be assumed that default free routing table is small. Yes, I agree completely. The default free routing table must have one route: a default route. See how frustrating that is? On Fri, Dec 30, 2011 at 4:49 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Ray Soucy wrote: But that is only the case if you let customers have a PI prefix (which I think is really required in a purist end-to-end model, but for the sake of argument...). Multihoming by routing, by the intermediate systems, is against the end to end principle, which is why it does not scale. The remote host would have no knowledge of other available prefixes As IP layer is connectionless, let transport or application layer carry the information on the prefixes to try to keep connections. (even if there is a path change, and a different path becomes favorable). The remote host can use IGP metric to know the initial best candidate and subsequent path changes. It can be assumed that default free routing table is small. In addition, the remote host may also use transport/application layer timeout to try other prefixes. The result is still a very large amount of overhead. You will still experience significant change propagation delay (slower than change propagation under the current model Not at all. Transport/application timeout is no different. Route propagation is no slower. Instead, smaller default free routing table means more rapid convergence. This all would be significantly more complex than IPv6 It was IPv6 which was expected to support multiple addresses to suppress routing table growth. The result is a complex protocol with halfhearted support for multiple addresses. We now know that it takes well over a decade for people to move to a protocol, even when it is almost operationally identical to its predecessor. Unlike IPv4, IPv6 is poorly operational and still needs protocol modifications, For example, multicast PMTUD causes ICMP implosion, which means rational operators filter ICMP packet too big often including those against unicast packets, which means PMTUD won't work. Yes, fixing it requires more than a decade. Then, it may be a good idea to obsolete SLAAC, which means IPv6 address can be only 8B long. You know, remembering 16B addresses is divine, which is an operational head ache. To be frank, you would have to build a completely new and parallel network and hope you could somehow convince people to adopt it Multihoming with multiple addresses works at transport/application layer over existing IPv4 and IPv6. Masataka Ohta -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Steven Bellovin wrote: VRRP? The Router Discovery Protocol (RFC 1256). But given how much more reliable routers are today than in 1984, I'm not convinced it's that necessary these days. VRRP is an absolutely essential protocol in today's Internet. We use it on every non-bgp customer port. Routers still have routing and performance issues, hardware failures and routine software upgrades. The layer2 infrastructure between the routers and the customer is also susceptible to various hardware/software/maintenance problems and fiber cuts and VRRP can help work around some of those. A nice side benefit is the virtual mac addresses that allow for migration to new routers without the mac address of the default gateway changing. One key advantage of VRRP over RA's is that you can have multiple instances on the same layer2 network (vlan) with different functions. It is very common to have different routers (routers, firewalls or load balancers) on the same vlan with different functions in hosting environments. It is also sometimes necessary to have multiple default gateways on the same vlan for load balancing or traffic engineering. RA/auto configuration is incompatible with all but the most trivial configurations. - Kevin
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
VRRP is still useful, and for those who find it useful it has been extended to IPv6 [RFC5798]. Vendors, such as Cisco, have already begun shipping functional implementations as well it would seem. There are certainly pieces of IPv6 that will need refinement (and we will likely see that happen over time, after it is dominant). Mobility and IPsec, for example, were touted as big benefits of IPv6, but they didn't end up being that important (or useful) in their current state. The ability to have multiple prefixes from different routers, and a failover mechanism was really a pre-NAT and pre-VRRP idea. It's not the common deployment that it was envisioned to be, and our expectations of how fast these things happen has become a lot higher. Still, minor extensions could be made to these standard to achieve a lot of the desired behavior, so I haven't given up on it all completely. It's hard to predict the future, and it's been over a decade since the design for IPv6 was solidified and began to be implemented. Let's not forget that what we call Ethernet today is very different from Bob Metcalfe's Ethernet. On Fri, Dec 30, 2011 at 11:47 AM, Kevin Loch kl...@kl.net wrote: Steven Bellovin wrote: VRRP? The Router Discovery Protocol (RFC 1256). But given how much more reliable routers are today than in 1984, I'm not convinced it's that necessary these days. VRRP is an absolutely essential protocol in today's Internet. We use it on every non-bgp customer port. Routers still have routing and performance issues, hardware failures and routine software upgrades. The layer2 infrastructure between the routers and the customer is also susceptible to various hardware/software/maintenance problems and fiber cuts and VRRP can help work around some of those. A nice side benefit is the virtual mac addresses that allow for migration to new routers without the mac address of the default gateway changing. One key advantage of VRRP over RA's is that you can have multiple instances on the same layer2 network (vlan) with different functions. It is very common to have different routers (routers, firewalls or load balancers) on the same vlan with different functions in hosting environments. It is also sometimes necessary to have multiple default gateways on the same vlan for load balancing or traffic engineering. RA/auto configuration is incompatible with all but the most trivial configurations. - Kevin -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 12/30/11 08:47 , Kevin Loch wrote: It is very common to have different routers (routers, firewalls or load balancers) on the same vlan with different functions in hosting environments. It is also sometimes necessary to have multiple default gateways on the same vlan for load balancing or traffic engineering. RA/auto configuration is incompatible with all but the most trivial configurations. As someone with rather abundant experience with both vrrp6 and multiple RAs per subnet I'm going to have to disagree with your there. it's not incompatible with the all but the most trivial configurations, you're distinguishing between default and non-default behavior. much as in ipv4 I may have a distinction between statically configured hosts, hosts which have a static configuration derived from dhcp and those with a dynamically generated configuration derived from dhcp. The static configured resources can happily coexist on a network where dynamically configured devices have diffrent default behavior. - Kevin
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 29 Dec 2011, at 13:46 , Masataka Ohta wrote: we must assume MTU of 1280B. But, as IPv6 extension headers can be as lengthy as 1000B or 2000B, no applications are guaranteed to work over IPv6. As IP is an unreliable datagram service, there are no guarantees, period. The presence of firewalls also removes any guarantees left in place after the previous point.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Multihoming with multiple addresses works at transport/application layer over existing IPv4 and IPv6. May be there is some light with Multipath TCP: http://www.ietf.org/proceedings/75/slides/mptcp-0.pdf http://datatracker.ietf.org/wg/mptcp/charter/ If you can live without UDP and other issues discussed in this bizarre discussion... -Christian -- Christian Esteve Rothenberg, Ph.D. Converged Networks Division (DRC) Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087 est...@cpqd.com.br www.cpqd.com.br
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Masataka Ohta wrote: Because that's the Microsoft quality. PERIOD. We knew it was a crooked game, but it was the only game in town.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
* Valdis Kletnieks: According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities. If it's the only possible spolution, how come 99.8% of the end nodes do just fine without it? Oh yeah.. Because there's a CPE which acts as a mediator, or the host uses some dial-up-type protocol which takes care of the IGP interaction. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
RE: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
(*) If you think I'm going to run an IGP on some of my file servers when default route to the world out the public 1G interface, and 5 static routes describing the private 10G network is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change. Well the only reason why you still have a good night sleep with the primary path in flames and all those in stone carved static routes is that your server is connected via ether channel to a couple of boxes with dual RPs and redundant power supplies running VSS or vPC and routers running vrrp All of this just because the end station just can't route around a failed link
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, 29 Dec 2011 21:53:29 +0900, Masataka Ohta said: IGP snooping is not necessary if the host have only one next hop router. You don't need an IGP either at that point, no matter what some paper from years ago tries to assert. :) pgpOVkl5pWSgU.pgp Description: PGP signature
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, 29 Dec 2011 09:14:20 GMT, Florian Weimer said: Because there's a CPE which acts as a mediator, or the host uses some dial-up-type protocol which takes care of the IGP interaction. So what percent of the *CPE* in the average cable-internet or DSL farm *actually uses* an IGP, and how much of it just does default route and be done with it, because there's only one cable head end to talk to or one central office to talk to at the other end of that DSL? In most topologies, you've got quite a ways to go before you actually need an IGP rather than just point default route upstream. (We've already heard somebody from the wireless world say they do all their stuff with L1/L2 games and leave L3 as static as possible). Because the last time I unhooked my home router, and connected the coax to one side of the cablemodem and an RJ-45 from the other side to my laptop, the entire routing information that I got from some Comcast server that was definitely the other side of my cablemodem was an IP, netmask, and default route via DHCP, which I don't think qualifies as an IGP. So tell me Florian, what's this magical IGP that my Belkin is doing that's invisible to my Dell when I hook it up directly? pgpoXmJJe5wMi.pgp Description: PGP signature
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
valdis.kletni...@vt.edu wrote: So what percent of the *CPE* in the average cable-internet or DSL farm *actually uses* an IGP, As I wrote: If a host receives RAs only from a router, the host can do nothing other than installing the router as the default router. If not, however, the host must directly be involved in IGP activities, or, the following end to end argument is applicable: IGP snooping is not necessary if the host have only one next hop router. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Sounds like we have one group saying that IPv6 is too complicated and that all the overhead of IPv6 had resulted in slow adoption. Meanwhile we have others saying it doesn't have enough functionality, and should also include IGP. Seems like IPv6 as it is has struck a balance somewhere in the middle. It's never going to be the perfect solution for every situation. There is a lot of academic and theoretical argument being made here, but not so much on the practical application side. I think this discussion went down hill when we started seeing people point to evidence that IPv6 is broken being special use cases that IPv4 can't even handle properly. On Thu, Dec 29, 2011 at 6:06 AM, Vitkovsky, Adam avitkov...@emea.att.com wrote: (*) If you think I'm going to run an IGP on some of my file servers when default route to the world out the public 1G interface, and 5 static routes describing the private 10G network is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change. Well the only reason why you still have a good night sleep with the primary path in flames and all those in stone carved static routes is that your server is connected via ether channel to a couple of boxes with dual RPs and redundant power supplies running VSS or vPC and routers running vrrp All of this just because the end station just can't route around a failed link -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Ray Soucy wrote: Sounds like we have one group saying that IPv6 is too complicated and that all the overhead of IPv6 had resulted in slow adoption. Meanwhile we have others saying it doesn't have enough functionality, and should also include IGP. Not at all. It is wrong that ND is so complicated that it even act as IGP proxy. To simplify the situation, let separate address resolution and IGP, which is the conventional wisdom of IPv4. ND became too complicated unnecessarily trying to offer incomplete and incorrect assistance from routers to nodes, even though the nodes should take care of themselves using information provided through IGP. Having a default router is fine if there is only one router. However, with multiple routers, default routers and ICMP redirects are nothing more than an incomplete proxy of IGP. There is a lot of academic and theoretical argument being made here, but not so much on the practical application side. Though NANOG may not be a good place to discuss about practical application side, it may be helpful to mention IPv6 is totally broken for the side. That is, as the length of IPv6 extension headers is unlimited and there are extension headers inserted automatically without application control, there is no guaranteed minimal payload size left for the transport layer. As PMTUD of IPv6 is proven to be inoperational: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf we must assume MTU of 1280B. But, as IPv6 extension headers can be as lengthy as 1000B or 2000B, no applications are guaranteed to work over IPv6. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 12/29/2011 7:59 AM, Cameron Byrne wrote: Next topic, ethernet is too chaotic and inefficient to deploy and support mission critical applications in LAN or WAN or data center. See IEEE1588v2 (Precision Time Protocol), SyncE, and Data center bridging (DCB) - all attempts to remedy such inefficiencies. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate
RE: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
... host systems should participate in IGP We tried that. It didn't scale well. The Internet today is very different than the Internet in 1981. -did you? I thought CLNS with plethora of ip addresses compared to ipv4 was buried before it could be widely deployed, I was not around back than but would like to know why ES-IS did not scale well when integrated IS-IS is still used primarily for great scalability
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Dec 29, 2011 6:38 AM, Ray Soucy r...@maine.edu wrote: Sounds like we have one group saying that IPv6 is too complicated and that all the overhead of IPv6 had resulted in slow adoption. Meanwhile we have others saying it doesn't have enough functionality, and should also include IGP. Seems like IPv6 as it is has struck a balance somewhere in the middle. It's never going to be the perfect solution for every situation. There is a lot of academic and theoretical argument being made here, but not so much on the practical application side. I think this discussion went down hill when we started seeing people point to evidence that IPv6 is broken being special use cases that IPv4 can't even handle properly. Yep. How about you guys take this nonsense off list. The first post was well intentioned, the rest has been FUD and sour grapes. Next topic, ethernet is too chaotic and inefficient to deploy and support mission critical applications in LAN or WAN or data center. Cb. On Thu, Dec 29, 2011 at 6:06 AM, Vitkovsky, Adam avitkov...@emea.att.com wrote: (*) If you think I'm going to run an IGP on some of my file servers when default route to the world out the public 1G interface, and 5 static routes describing the private 10G network is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change. Well the only reason why you still have a good night sleep with the primary path in flames and all those in stone carved static routes is that your server is connected via ether channel to a couple of boxes with dual RPs and redundant power supplies running VSS or vPC and routers running vrrp All of this just because the end station just can't route around a failed link -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Dec 29, 2011, at 2:27 AM, Vitkovsky, Adam wrote: ... host systems should participate in IGP We tried that. It didn't scale well. The Internet today is very different than the Internet in 1981. -did you? I thought CLNS with plethora of ip addresses compared to ipv4 was buried before it could be widely deployed, I was not around back than but would like to know why ES-IS did not scale well when integrated IS-IS is still used primarily for great scalability ??? CLNS carried NSAPs, not IP addresses. ES-IS was the protocol between hosts and routers, very much akin to ARP. IS-IS was the IGP used for CLNS. Yes, it's the same one that we use today for IP. Even in the ISO model, hosts did not participate in IS-IS. There was no particular scalability problem with ES-IS, other than the mcast burden that it imposed on the link layer. This is not radically different than the burden that ARP broadcasts require. Limit your broadcast domains. Tony
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
valdis.kletni...@vt.edu wrote: IGP snooping is not necessary if the host have only one next hop router. You don't need an IGP either at that point, no matter what some paper from years ago tries to assert. :) IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly. Beyond that, if there are multiple routers, having a default router and relying on the default router for forwarding to other routers and/or supplying ICMP redirects stops working when the default router, the single point of failure, goes down, which is the incompleteness and/or incorrectness predicted by the paper of the end to end argument. Considering that the reason to have multiple routers should be for redundancy, there is no point to use one of them as the default router. Developing more complicated IGP proxy makes the incompleteness and the incorrectness not disappear but more complicated. Masataka Ohta PS Note that the paper was written in 1984, where as RFC791 was written in 1981.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Dec 29, 2011, at 5:30 16PM, Masataka Ohta wrote: valdis.kletni...@vt.edu wrote: IGP snooping is not necessary if the host have only one next hop router. You don't need an IGP either at that point, no matter what some paper from years ago tries to assert. :) IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly. Beyond that, if there are multiple routers, having a default router and relying on the default router for forwarding to other routers and/or supplying ICMP redirects stops working when the default router, the single point of failure, goes down, which is the incompleteness and/or incorrectness predicted by the paper of the end to end argument. Considering that the reason to have multiple routers should be for redundancy, there is no point to use one of them as the default router. VRRP? The Router Discovery Protocol (RFC 1256). But given how much more reliable routers are today than in 1984, I'm not convinced it's that necessary these days. Developing more complicated IGP proxy makes the incompleteness and the incorrectness not disappear but more complicated. Masataka Ohta PS Note that the paper was written in 1984, where as RFC791 was written in 1981. There was a lot less understanding of the difference between hosts and routers in 1984 than there is today -- if nothing else, note how 4.2BSD and 4.3BSD considered all multihomed machines to be routers. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Fri, 30 Dec 2011 07:30:16 +0900, Masataka Ohta said: IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly. Which is sufficient for 99.8% of hosts out there. Beyond that, if there are multiple routers, having a default router and relying Yes yes we know, and we've understood this for a quarter century or so. My disagreement is that even though 99.8% of machines *don't* have multiple routers, you seem to be pedantically insisting that some sort of IGP is mandatory for *all* end hosts, even though only 0.2% or so will actually see any benefit at all.. pgpRDdcTiQVbK.pgp Description: PGP signature
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
In message 68424.1325204...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: On Fri, 30 Dec 2011 07:30:16 +0900, Masataka Ohta said: IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly. Which is sufficient for 99.8% of hosts out there. Beyond that, if there are multiple routers, having a default router and relying Yes yes we know, and we've understood this for a quarter century or so. My disagreement is that even though 99.8% of machines *don't* have multiple routers, you seem to be pedantically insisting that some sort of IGP is mandatory for *all* end hosts, even though only 0.2% or so will actually see any benefit at all. Well I'd like to be able to plug in the cable router and the DSL router at home and have it all just work. Just because it is 0.2% today doesn't mean that it will be 0.2% in the future. As home users get more and more dependent on the internet working having diverse, independent network connectivity will become more and more important. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Fri, 30 Dec 2011 12:12:43 +1100, Mark Andrews said: Well I'd like to be able to plug in the cable router and the DSL router at home and have it all just work. Just because it is 0.2% today doesn't mean that it will be 0.2% in the future. As home users get more and more dependent on the internet working having diverse, independent network connectivity will become more and more important. Agreed. But did you plug the cable router and the DSL router both into your PC, or into yet another box that needs routing smarts and then your PC just needs to know talk to the smart box? (Hint - if the cable router and the DSL router are both plugged into your PC, how do all the *other* devices in your house reach the internet? :) pgpiuEXxDSHgh.pgp Description: PGP signature
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 12/29/2011 8:12 PM, Mark Andrews wrote: Well I'd like to be able to plug in the cable router and the DSL router at home and have it all just work. Well, that's not too far removed from the plugged-in laptop with the wireless still active. Toss-up which one wins default route. What would you like it to do? BGP feeds from both (likely not happening)? Defaults from both? Or you just want active/passive failover? The real-world case for host routing (IMHO) is a server with a public interface, an administrative interface, and possibly a third path for data backups (maybe four if it's VMware/VMotion too). Unless the non-public interfaces are flat subnets, you need some statics (today). It can be a challenge to get SysAdmins in a co-operative mindset to route that correctly (and repetitively if you have a server farm). I would be walking the fence on the virtues of automatic route discovery in that case versus the security of static routes/configurations. But home use from a host perspective? Jeff
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Steven Bellovin wrote: Considering that the reason to have multiple routers should be for redundancy, there is no point to use one of them as the default router. VRRP? The Router Discovery Protocol (RFC 1256). But given how much more reliable routers are today than in 1984, I'm not convinced it's that necessary these days. How much, do you think, more reliability required to the Internet today than in 1984? There was a lot less understanding of the difference between hosts and routers in 1984 than there is today -- if nothing else, note how 4.2BSD and 4.3BSD considered all multihomed machines to be routers. Unlike routers, multihomed machines without forwarding should listen IGP but must not advertise routes, which was well understood very well even at that time. It is the right thing to do, as is proven by the 99.8% argument that Microsoft don't do so. :-) Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Dec 29, 2011, at 7:00 PM, Jeff Kell jeff-k...@utc.edu wrote: The real-world case for host routing (IMHO) is a server with a public interface, an administrative interface, and possibly a third path for data backups (maybe four if it's VMware/VMotion too). Unless the non-public interfaces are flat subnets, you need some statics (today). It can be a challenge to get SysAdmins in a co-operative mindset to route that correctly (and repetitively if you have a server farm). What I've done in that case as a sysadmin was a default out the internet interface and some sort of ospf daemon to handle the rest. If I want a host to learn routing, I put a routing daemon on it. Otherwise I just use a default route. I don't see why this changes with IPv6.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
In message 69748.1325208...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: On Fri, 30 Dec 2011 12:12:43 +1100, Mark Andrews said: Well I'd like to be able to plug in the cable router and the DSL router at home and have it all just work. Just because it is 0.2% today doesn't mean that it will be 0.2% in the future. As home users get more and more dependent on the internet working having diverse, independent network connectivity will become more and more important. Agreed. But did you plug the cable router and the DSL router both into your PC, or into yet another box that needs routing smarts and then your PC just needs to know talk to the smart box? (Hint - if the cable router and the DSL router are both plugged into your PC, how do all the *other* devices in your house reach the internet? :) I'm curious. How did you get directly connected to the PC from the above description? The routers would be connected to the internal *network*. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
OK, this is getting ridiculous. Let's assume that we have a model where host systems receive the global routing table from service providers. The stated reason for this is so that they could make their own routing decisions when multi-homed environment. Presumably with each ISP connected to a L2 device; let's say an Ethernet Switch. So now we have ISP A, B, and let's even add C. Each are providing all available routes in the global table, and path information, allowing the host to make intelligent routing decisions. Unfortunately, for bi-directional communication, the prefix assigned to the customer must be provider independent. It's a residential service so maybe they have a single 64-bit prefix. So we now need ISP A, B, and C to be announcing that prefix. Congratulations, you have just created a model where every customer would have their own entry in the global table (since route summarization and aggregation is now impossible), one that is exponentially greater than the production IP global table today. But that is only the case if you let customers have a PI prefix (which I think is really required in a purist end-to-end model, but for the sake of argument...). We could, of course, only provide customers with the global table, and have each ISP give hosts a different prefix. This would allow for the selection of the best path by the host, but once that communication is established it would be locked into that path. The remote host would have no knowledge of other available prefixes (even if there is a path change, and a different path becomes favorable). To get around this we could develop another message that allows a host to announce alternative addresses to other hosts; which means systems now also need to keep a table of alternate peer addresses, and have the ability to quickly detect changes in path availability and quality. The result is still a very large amount of overhead. You will still experience significant change propagation delay (slower than change propagation under the current model as it would be more complex, involve exponentially more peers, paths, etc, and be performed on commodity hardware). This all would be significantly more complex than IPv6 (which is already claimed, by the proponents of the beloved end-to-end model, to be too complex and have too much overhead), it would introduce even more delay (another complaint) than IPv6 due to that complexity. Limitations aside. We now know that it takes well over a decade for people to move to a protocol, even when it is almost operationally identical to its predecessor. Getting buy-in for such a fundamental shift in how the Internet is build would be almost impossible at this point. To be frank, you would have to build a completely new and parallel network and hope you could somehow convince people to adopt it (when everything they want works just fine on the old network). I honestly can't believe we're even having this discussion. It's really bonkers. 2011/12/29 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: valdis.kletni...@vt.edu wrote: IGP snooping is not necessary if the host have only one next hop router. You don't need an IGP either at that point, no matter what some paper from years ago tries to assert. :) IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly. Beyond that, if there are multiple routers, having a default router and relying on the default router for forwarding to other routers and/or supplying ICMP redirects stops working when the default router, the single point of failure, goes down, which is the incompleteness and/or incorrectness predicted by the paper of the end to end argument. Considering that the reason to have multiple routers should be for redundancy, there is no point to use one of them as the default router. Developing more complicated IGP proxy makes the incompleteness and the incorrectness not disappear but more complicated. Masataka Ohta PS Note that the paper was written in 1984, where as RFC791 was written in 1981. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Just to clear up a few misconceptions: begin explanation current situation Router advertisements are exactly what the name suggests, routers advertising their presence. The first function of router advertisements is to tell hosts where the routers are, so the hosts can install a default route. No RA means hosts won't send the router their packets. Of course routers that only talk to other routers don't need to send out RAs although nothing bad happens if they do so vendors may opt to send them out by default. All other functionality provided by RAs is optional. The first of those additional options the prefix option. This allows hosts to know which addresses are reachable on the local subnet so packets to those addresses don't have to go through a router but can be sent directly. Multiple prefix options may be present in an RA. Then there is the autonomous autoconfiguration (A) flag, which tells hosts that they should configure an address for themselves using the prefix in a prefix option. So only when at least one prefix option with the A flag set is present in an RA and the prefix length for that prefix is 64, stateless address autoconfiguration will be performed. Additional RA options can provide information such as a reduced MTU to be used on a subnet or a list of DNS server addresses. Unlike everything else mentioned so far, the latter is not very widely implemented. For DHCPv6, there are three variants: one that provides prefixes to routers, one that provides individual addresses (presumably) to hosts, and one that provides additional information such as DNS addresses. The first two require a stateful version of the DHCPv6 exchange to be performed, while the additional information can also be acquired using a lighter weight stateless exchange. Unless I'm very much mistaken, the DHCPv6 server can only perform the function the client has asked for. DHCPv6 is different from IPv4 DHCP in many ways, for instance the stateful/stateless distinction and the use of DUIDs rather than client identifiers. More importantly, DHCPv6 doesn't provide a prefix length or default gateway. This means that RAs are always necessary to provide this information (although some implementations may function without having explicitly learned the prefix length they should use). The trouble with having two mechanisms to do the same thing (stateless autoconfig and DHCPv6 address assignment) is how to decide which one to use. For this we have the M and O bits in RA. If M is set stateful DHCPv6 should be initiated for requesting an address and other information. If only the O bit is set stateless DHCPv6 should be initiated by hosts to request only other information. If both M and O are zero then no DHCPv6 should be initiated. Windows Vista and up and MacOS 10.7 support DHCPv6 address assignment. This means that as of six months ago, it became possible to assume DHCPv6 support in current versions of mainstream OSes. Before that, some of them lacked this capability so effectively, turning off stateless autoconfig and solely using DHCPv6 was impossible. issues and way forward Stateless autoconfig is a very nice system in un- or lightly managed environments, where it provides stable addresses to hosts without the need to have a central server keep track of those addresses using non-volatile storage. Unfortunately the DNS info isn't widely supported so at this point, at least stateless DHCPv6 is also needed to provide this information. In more tightly managed environments, stateless autoconfig has the downside that the hosts choose their addresses autonomously, so the information about which host has which address at which point in time isn't easily available to be logged. We have now reached the point were it's possible to turn off stateless autoconfig and use DHCPv6 address assignment instead to accommodate such logging. Of course none of this is bullet proof. Like with IPv4, there is some assumption that people on a shared subnet play nice. This may be an incorrect assumption. In that case, significant filtering and additional logging of L2 parameters may be necessary. Such features are not as widely available for IPv6 as for IPv4. There are some situations where it can be useful to give different hosts different information using DHCPv6, including information that is now provided using RAs, which are of course the same from the viewpoint of every host on a given subnet. In addition to that, some people just don't like RAs and want to run their network without them. These two groups want default gateway information to be added to DHCPv6 to accommodate those needs/wants. However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence. With DHCP, it is possible to inject incorrect information. In my opinion, people are underestimating the
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Iljitsch van Beijnum wrote: Just to clear up a few misconceptions: Only to add yet another misconception without any clearing up? Router advertisements are exactly what the name suggests, routers advertising their presence. The first function of router advertisements is to tell hosts where the routers are, OK, so far. so the hosts can install a default route. WRONG. Routers are not a default route. If a host receives RAs only from a router, the host can do nothing other than installing the router as the default router. If not, however, the host must directly be involved in IGP activities, or, the following end to end argument is applicable: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. Masataka Ohta PS Granted that the notion of default router of IPv4 is no better than that of IPv6.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: Granted that the notion of default router of IPv4 is no better than that of IPv6. Please present a reasonable alternative. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Ray Soucy wrote: Granted that the notion of default router of IPv4 is no better than that of IPv6. Please present a reasonable alternative. According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities. See the paper by Saltzer et. al. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 28 Dec 2011, at 13:26 , Ray Soucy wrote: Granted that the notion of default router of IPv4 is no better than that of IPv6. Please present a reasonable alternative. Obviously reducing down the entire DFZ to a single default route is a bad case of premature optimization, which we all know is how so many engineering efforts get into trouble. The right way to handle this would be for hosts to engage in both inter and intra domain routing with local routers, and then do their own aggregation if and when desired. Iljitsch PS. :-)
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Iljitsch van Beijnum wrote: Granted that the notion of default router of IPv4 is no better than that of IPv6. Please present a reasonable alternative. Obviously reducing down the entire DFZ to a single default route is a bad case of premature optimization, Stop confusing default router and default route. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities. See the paper by Saltzer et. al. So your entire argument is based on an academic paper from 1981 and that host systems should participate in IGP. We tried that. It didn't scale well. The Internet today is very different than the Internet in 1981. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Wed, 28 Dec 2011 21:56:19 +0900, Masataka Ohta said: According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities. That's only for hosts that are actively trying to communicate on more than one interface at a time, and even then quite often the *actual* right answer isn't run an IGP, it's insert static routes for the subnets you need to reach via the other interface(*). Meanwhile, out in the real world, 98% of actual hosts have a *really* easy routing decision - they can make a choice of any of one routers to reach the destination. If it's a laptop that has both a wireless and a wired connection active, usually a simple prefer wired or prefer wireless is sufficient. Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by default? If not, why does the net continue to function just fine without it? Hmm.. Thought so. Maybe an IGP on end hosts isn't quite as needed on production networks as an academic paper from years ago might suggest. (*) If you think I'm going to run an IGP on some of my file servers when default route to the world out the public 1G interface, and 5 static routes describing the private 10G network is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change. pgpmZpbgqoXGx.pgp Description: PGP signature
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 12/28/2011 03:13, Iljitsch van Beijnum wrote: However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence. Unless you have a malicious user on the network in which case all traffic immediately switches to the malicious user's gateway. This is in contrast to DHCP where the similar attack only affects new/renewing hosts. I'm aware that SEND is trying to solve this problem, but it's not yet deployed. With DHCP, it is possible to inject incorrect information. In my opinion, people are underestimating the problems that occur with IPv4 DHCP and the additional issues that would be introduced in IPv6 by adding this feature. I think that people already know of and have solutions for the security issues that exist for DHCP today. Second, publishing specifications, implementing them and waiting for users to adopt them takes a very, very long time. For DHCPv6 support, the time from first publication (2003) until wide availability (2011) has been 8 years. Are we ready to live in a half-baked world for another half a decade or more just so we can add this feature, while layer 2 filtering and VLANs more easily support similar functionality? 10-12 years ago I attempted to make 2 points to the IPv6 literati. First that IPv6 would not be widely adopted in the enterprise until it had full DHCP parity with v4. Second that the easiest way to do that would be to declare all existing DHCPv4 options that are relevant to IPv6 as existing in DHCPv6 by fiat, and to prevent new v6-only options from using option numbers that already exist for v4 (and vice versa). I was laughed out of the room on both counts. (If anyone wants more of the history, see https://www.ietf.org/mail-archive/web/ipv6/current/msg15129.html) The good news is that it's not too late to fix DHCPv6. We're at a watershed moment where it's just possible that we'll get the ability to assign a default gateway added to it due to, for lack of a better term, market forces. This would be a major paradigm shift. As you point out the development lead time on stuff like that is rather painful, however if we took advantage of the camel's nose under the tent and included everything relevant that DHCPv4 can do in that update, we'd be in a pretty good condition in a year or so. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Wed, Dec 28, 2011 at 18:16, Doug Barton do...@dougbarton.us wrote: On 12/28/2011 03:13, Iljitsch van Beijnum wrote: However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence. Unless you have a malicious user on the network in which case all traffic immediately switches to the malicious user's gateway. This is in contrast to DHCP where the similar attack only affects new/renewing hosts. I'm aware that SEND is trying to solve this problem, but it's not yet deployed. Right, the window is tighter for DHCPv4 as compared to SLAAC. That is why RA Guard is a really useful thing we should support to prevent accidental maliciousness, and perhaps enhance RA Guard to account for more skillful evasive (fragmented, etc.) malicious RAs. In the former case, a simple ARP-spoofing attack (for IPv6, ND spoofing) and you are back in ... but that is a separate paragraph :). With DHCP, it is possible to inject incorrect information. In my opinion, people are underestimating the problems that occur with IPv4 DHCP and the additional issues that would be introduced in IPv6 by adding this feature. I think that people already know of and have solutions for the security issues that exist for DHCP today. And what is the percentage of environments that use those things? (From personal experience, 0% ... although certainly it is higher than that.) And yet, their IPv4 networks are up running just fine ... In the big picture, this has always been fairly low on the scale. Make RA Guard a norm for host ports and move forward. Second, publishing specifications, implementing them and waiting for users to adopt them takes a very, very long time. For DHCPv6 support, the time from first publication (2003) until wide availability (2011) has been 8 years. Are we ready to live in a half-baked world for another half a decade or more just so we can add this feature, while layer 2 filtering and VLANs more easily support similar functionality? 10-12 years ago I attempted to make 2 points to the IPv6 literati. First that IPv6 would not be widely adopted in the enterprise until it had full DHCP parity with v4. Second that the easiest way to do that would be to declare all existing DHCPv4 options that are relevant to IPv6 as existing in DHCPv6 by fiat, and to prevent new v6-only options from using option numbers that already exist for v4 (and vice versa). I was laughed out of the room on both counts. (If anyone wants more of the history, see https://www.ietf.org/mail-archive/web/ipv6/current/msg15129.html) The good news is that it's not too late to fix DHCPv6. We're at a watershed moment where it's just possible that we'll get the ability to assign a default gateway added to it due to, for lack of a better term, market forces. This would be a major paradigm shift. As you point out the development lead time on stuff like that is rather painful, however if we took advantage of the camel's nose under the tent and included everything relevant that DHCPv4 can do in that update, we'd be in a pretty good condition in a year or so. And, FWIW, I support making DHCPv6 more complete as well. (Although, annoying to some, I don't mind DHCPv6 waiting for the M bit to be sent in an RA - again separate paragraph!) /TJ
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
facts deleted Second, publishing specifications, implementing them and waiting for users to adopt them takes a very, very long time. For DHCPv6 support, the time from first publication (2003) until wide availability (2011) has been 8 years. Are we ready to live in a half-baked world for another half a decade or more just so we can add this feature enterprise: but you want us to do v6 today, why didn't you put it in when there was time then. Let us know when it's ready, ktnxbye I would like to make the following suggestion: rather than having DHCPv6 impose a default gateway with all the issues that that creates, why not implement a router preference option. This way, DHCPv6 can be used to select the correct default gateway from the list of possible default gateways that announce their presence through RAs sounds like the which half of the baby would you like option. I don't have a dog in this fight but understand the dhcp only option is so the dhcp guys manage * and don't have to talk to the router guys other than to tell them to fix the router when it breaks. brandon
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
valdis.kletni...@vt.edu wrote: According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities. That's only for hosts that are actively trying to communicate on more than one interface at a time, Note that the end to end argument has the following statement I omitted to quote: (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) That is, there are incomplete solutions by intermediate systems which sometimes work. and even then quite often the *actual* right answer isn't run an IGP, it's insert static routes for the subnets you need to reach via the other interface(*). With manual configuration, you can do anything. But, aren't we talking about autoconfiguration? If it's a laptop that has both a wireless and a wired connection active, usually a simple prefer wired or prefer wireless is sufficient. Usually? Can you see the word complete in the end to end argument? Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by default? Sanity check with Windows? Are you sure? If not, why does the net continue to function just fine without it? It is often incomplete and incorrect unnecessarily requiring manual reconfigurations. (*) If you think I'm going to run an IGP on some of my file servers when default route to the world out the public 1G interface, and 5 static routes describing the private 10G network is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change. If you are saying SLAAC is not enough in your case with complicated manual management, I don't think I have to argue against you on how to simplify it. Masataka Ohta
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Wed, Dec 28, 2011 at 6:16 PM, Doug Barton do...@dougbarton.us wrote: On 12/28/2011 03:13, Iljitsch van Beijnum wrote: Second, publishing specifications, implementing them and waiting for users to adopt them takes a very, very long time. For DHCPv6 support, the time from first publication (2003) until wide availability (2011) has been 8 years. Are we ready to live in a half-baked world for another half a decade or more just so we can add this feature, while layer 2 filtering and VLANs more easily support similar functionality? 10-12 years ago I attempted to make 2 points to the IPv6 literati. First that IPv6 would not be widely adopted in the enterprise until it had full DHCP parity with v4. Second that the easiest way to do that would +1000 be to declare all existing DHCPv4 options that are relevant to IPv6 as existing in DHCPv6 by fiat, and to prevent new v6-only options from using option numbers that already exist for v4 (and vice versa). I was laughed out of the room on both counts. (If anyone wants more of the similarly folks keep laughing (or at least harumphing loudly) when enterprise folk say: Hey, I use dhcp today for a large number of things, I can't NOT use it going forward, support the features in v4 dhcp that I use in your new v6 thingy. anyway, it seems to be getting slightly better, bolting more crud on ND so you can continue to say: Yea, but you SHOULD use is wasted breath. -chris
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, 29 Dec 2011 11:51:00 +0900, Masataka Ohta said: valdis.kletni...@vt.edu wrote: Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by default? Sanity check with Windows? Are you sure? It's a quick sanity check to this statment: According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities. If it's the only possible spolution, how come 99.8% of the end nodes do just fine without it? Oh yeah.. Note that the end to end argument has the following statement I omitted to quote: (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) That is, there are incomplete solutions by intermediate systems which sometimes work. For sometimes == 99.8% of the net. If you are saying SLAAC is not enough in your case with complicated manual management, I don't think I have to argue against you on how to simplify it. It got simplfied with a handful of static routes and no IGP and no SLAAC and no DHCP of any flavor. ;) pgpiwXdenhdbx.pgp Description: PGP signature
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
valdis.kletni...@vt.edu wrote: Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by default? Sanity check with Windows? Are you sure? It's a quick sanity check to this statment: According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities. If it's the only possible spolution, how come 99.8% of the end nodes do just fine without it? Oh yeah.. Because that's the Microsoft quality. PERIOD. Masataka Ohta
