Re: IPv6 Deployment for the LAN
On Sun, 18 Oct 2009 09:03:12 +0100 Andy Davidson a...@nosignal.org wrote: On 18 Oct 2009, at 01:55, Ray Soucy wrote: The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. [...] Needless to say, the thought of being able to enable IPv6 on a per- host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Hi, Roy -- Good summary, thanks for the write-up. I reluctantly just use SLAAC on our own office LANs because, we're still quite a small and nimble team, therefore we can secure our network against our SLAAC security concerns by locking down access to the network. I realise this isn't going to work for everyone, as it doesn't fit well for the security needs of your much larger campus network. It also doesn't work for some of our customers who have DHCP in their toolbox for provision certain hosting environments. DHCPv6 today lacks default-router option support, so you are left with some pretty awful choices if you don't want to use the router solicitation/advertisement, err, 'features' in SLAAC : I'm curious what the issue is with not having a default-router option in DHCPv6? If it's because somebody could start up a rogue router and announce RAs, I think a rogue DHCPv6 server is (or will be) just as much a threat, if not more of one - I think it's more likely server OSes will include DHCPv6 servers than RA servers. - Static route on the device - Actually, you could use the *same* link-local address to keep this the same on all devices on your network, which you continue to support long after a better protocol comes along. This reduces your support overhead. - end user runs some routing protocol - I don't want to give my router the extra work though. And it feels like a stupid idea. And end user OSes don't tend to have them installed. - Don't roll v6 beyond engineering teams, until something better comes along - Sadly, I think that this is the option people are taking. :-( I don't know the history of the process that led to DHCPv6 ending up crippled, and I have to admit that it's not clear how I signal this and to whom, but for the avoidance of doubt: this operator would like his tools back please. Support default-routing options for DHCPv6 ! Andy -- Regards, Andy Davidson+44 (0)20 7993 1700www.netsumo.com NetSumo Specialist ISP/networks consultancy, Whitelabel 24/7 NOC
Re: IPv6 Deployment for the LAN
On 18/10/2009, at 9:03 PM, Andy Davidson wrote: I don't know the history of the process that led to DHCPv6 ending up crippled, and I have to admit that it's not clear how I signal this and to whom, but for the avoidance of doubt: this operator would like his tools back please. Support default-routing options for DHCPv6 ! I think what you really want is an on-link prefix option in DHCPv6. Or at least, you'd need that as well as a default router option. As I've said before, RA does not mean SLAAC. DO NOT use the two words interchangeably. We have two address configuration mechanisms, RA is the transport for one (SLAAC) and is the hint to use another (DHCPv6 stateful). The use of RA does NOT require the use of either mechanism. Without RA, we don't know which to use, without manual configuration. I for one don't want to have to fool around every time I move to a new network, and I'm a tech guy. Can we put this in to a FAQ somewhere, I write this in almost every IPv6 thread that comes up on NANOG. The reason Ray's perceived problem exists is that when using DHCPv6 stateful for address configuration, you should also include the prefix in an RA message. This is because DHCPv6 doesn't give out prefix lengths, it only gives out addresses. There is an option (the A bit) with each prefix in an RA message, which says whether this prefix can be used for SLAAC or not (1 = SLAAC). Ray's perception (fear?) is that there are some implementations that will ignore the contents of this bit, and use the prefix for SLAAC regardless. I'm interested to see if these implementations actually exist, I haven't come across any myself or heard of any - but I've not been looking. Anyway, start here for a discussion of prefix lengths in DHCPv6: http://www.ietf.org/mail-archive/web/dhcwg/current/msg07412.html -- Nathan Ward
Re: IPv6 Deployment for the LAN
On 18/10/2009, at 9:22 PM, Mark Smith wrote: I'm curious what the issue is with not having a default-router option in DHCPv6? This mechanism is provided by RA. RA is needed to tell a host to use DHCPv6, so RA is going to be there whenever you have DHCPv6. There's no point putting a default router option in to DHCPv6 at this point. If it's because somebody could start up a rogue router and announce RAs, I think a rogue DHCPv6 server is (or will be) just as much a threat, if not more of one - I think it's more likely server OSes will include DHCPv6 servers than RA servers. Perhaps, but if you're operating a LAN segment you're going to want to filter rouge RA and DHCPv6 messages from your network, just like you do with DHCP in IPv4. Filtering RA and DHCPv6 are done in very similar ways. -- Nathan Ward
Re: IPv6 Deployment for the LAN
On Sun, Oct 18, 2009 at 09:29:41PM +1300, Nathan Ward wrote: Perhaps, but if you're operating a LAN segment you're going to want to filter rouge RA and DHCPv6 messages from your network, just like you do with DHCP in IPv4. Filtering RA and DHCPv6 are done in very similar ways. Unfortunately, no. Many/most LAN switches don't support filtering IPv6 traffic yet. Of those that do, most only support TCP/UDP ports but not ICMPv6 types or RA specifically. Therefore, right now it is probably easier to find support to filter DHCPv6 (udp source port 547) than it is to find support to filter RA. This is a real problem even for people who are not using IPv6 right now and have no desire to use IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue box on the LAN, breaking access to dual-stack servers on the Internet. The impact is worse when you start trying to roll out IPv6 dual-stack to selected servers on your own LAN.
Re: IPv6 Deployment for the LAN
On 18/10/2009, at 9:52 PM, Chuck Anderson wrote: On Sun, Oct 18, 2009 at 09:29:41PM +1300, Nathan Ward wrote: Perhaps, but if you're operating a LAN segment you're going to want to filter rouge RA and DHCPv6 messages from your network, just like you do with DHCP in IPv4. Filtering RA and DHCPv6 are done in very similar ways. Unfortunately, no. Many/most LAN switches don't support filtering IPv6 traffic yet. Of those that do, most only support TCP/UDP ports but not ICMPv6 types or RA specifically. Therefore, right now it is probably easier to find support to filter DHCPv6 (udp source port 547) than it is to find support to filter RA. This is a real problem even for people who are not using IPv6 right now and have no desire to use IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue box on the LAN, breaking access to dual-stack servers on the Internet. The impact is worse when you start trying to roll out IPv6 dual-stack to selected servers on your own LAN. This is true for now until we get switches with code to do this, and also doesn't change my point. -- Nathan Ward
Re: IPv6 Deployment for the LAN
On 18 Oct 2009, at 09:22, Mark Smith wrote: If it's because somebody could start up a rogue router and announce RAs, I think a rogue DHCPv6 server is (or will be) just as much a threat, if not more of one - I think it's more likely server OSes will include DHCPv6 servers than RA servers. Disagree - rogue offers affect people without a lease, so the impact of an attack is not immediate. Filtering DHCP on v4 is well understood, an update to current operational practice rather than a new system. On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Andy
Re: IPv6 Deployment for the LAN
On 18/10/2009, at 11:02 PM, Andy Davidson wrote: On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. -- Nathan Ward
RE: IPv6 Deployment for the LAN
This is a real problem even for people who are not using IPv6 right now and have no desire to use IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue box on the LAN Answer = RA Guard - push your vendor-of-choice to implement it :). /TJ -Original Message- From: Chuck Anderson [mailto:c...@wpi.edu] Sent: Sunday, October 18, 2009 4:52 AM To: nanog@nanog.org Subject: Re: IPv6 Deployment for the LAN snip Unfortunately, no. Many/most LAN switches don't support filtering IPv6 traffic yet. Of those that do, most only support TCP/UDP ports but not ICMPv6 types or RA specifically. Therefore, right now it is probably easier to find support to filter DHCPv6 (udp source port 547) than it is to find support to filter RA. This is a real problem even for people who are not using IPv6 right now and have no desire to use IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue box on the LAN, breaking access to dual-stack servers on the Internet. The impact is worse when you start trying to roll out IPv6 dual-stack to selected servers on your own LAN.
RE: IPv6 Deployment for the LAN
RA is needed to tell a host to use DHCPv6 This is not ideal. That is entirely a matter of opinion, and one frequently debated still. FWLIW - I think RAs are a perfectly fine way to distribute information about the router itself, and to provide hints about the environment (e.g. - Yes, we do Stateful DHCPv6 here (+M, and +O' as well ...) /TJ -Original Message- From: Andy Davidson [mailto:a...@nosignal.org] Sent: Sunday, October 18, 2009 6:02 AM To: NANOG list Subject: Re: IPv6 Deployment for the LAN On 18 Oct 2009, at 09:22, Mark Smith wrote: If it's because somebody could start up a rogue router and announce RAs, I think a rogue DHCPv6 server is (or will be) just as much a threat, if not more of one - I think it's more likely server OSes will include DHCPv6 servers than RA servers. Disagree - rogue offers affect people without a lease, so the impact of an attack is not immediate. Filtering DHCP on v4 is well understood, an update to current operational practice rather than a new system. On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Andy
Re: IPv6 Deployment for the LAN
On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: On 18/10/2009, at 11:02 PM, Andy Davidson wrote: On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. -- Nathan Ward Because RA assumes that all routers are created equal. Because RA is harder to filter. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. I think those are the top 3. I can't think of the rest of the list off the top of my head as my brain still thinks it's 5 AM. Owen
RE: IPv6 Deployment for the LAN
Because RA assumes that all routers are created equal. Because RA is harder to filter. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. Off the top of my head, the easiest answers are: Default Router Preference, well supported on hosts and routers, doesn't cover 100% of every corner case, but then again - nothing does :) RA Guard - push vendors to implement (otherwise, other monitoring/preventative measures are available - but 3rd party) And I still think the router is in a (much) better position to inform hosts about the router's and link's information than some server three hops --- that way. /TJ -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Sunday, October 18, 2009 8:11 AM To: Nathan Ward Cc: NANOG Subject: Re: IPv6 Deployment for the LAN On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: On 18/10/2009, at 11:02 PM, Andy Davidson wrote: On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. -- Nathan Ward Because RA assumes that all routers are created equal. Because RA is harder to filter. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. I think those are the top 3. I can't think of the rest of the list off the top of my head as my brain still thinks it's 5 AM. Owen
Re: IPv6 Deployment for the LAN
On 19/10/2009, at 1:10 AM, Owen DeLong wrote: On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: On 18/10/2009, at 11:02 PM, Andy Davidson wrote: On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. Because RA assumes that all routers are created equal. RFC4191 Because RA is harder to filter. DHCP in IPv4 was hard to filter before vendors implemented it, too. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. Security concerns would be useful to explore. Can you expand on this? -- Nathan Ward
Re: IPv6 Deployment for the LAN
Nathan Ward wrote: On 19/10/2009, at 1:10 AM, Owen DeLong wrote: On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: On 18/10/2009, at 11:02 PM, Andy Davidson wrote: On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. Because RA assumes that all routers are created equal. RFC4191 In some cases different devices on a segment need a different default router (for default). This is the fundamental problem with RA's, they shotgun the entire segment. Because RA is harder to filter. DHCP in IPv4 was hard to filter before vendors implemented it, too. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. Security concerns would be useful to explore. Can you expand on this? What would be useful would be having the option to give a default router to a dhcpv6 client, and having vrrpv6 work without RA's. Why can't we have those options in our toolbox in addition to this continuously evolving RA+hacks? - Kevin
Re: {SPAM?} Re: IPv6 Deployment for the LAN
I generally agree with the design of RA and using DHPCv6 as a supplement to it. The problems here seem to be more along the lines of implementation in clients. I suspect it will take some time for the dust to settle and vendors to get their act together. I notice that Cisco has a prefix no-autoconfig statement in some releases in addition to no-advertise. The code I'm running doesn't seem to support this yet. I'll have to dig deeper to see what series support it and how it interacts with hosts. If hosts actually do respect it, it will likely lead to our migration to using /64s, though a lot will depend on the time tables we can set to move to code that will support this on our routers. I do remember seeing some notes about some implementations of IPv6 simply ignoring that flag for the prefix, though, so I'm still hesitant to endorse it until I've had a chance to test a wide variety of hosts in this configuration. Still, using a prefix other than a /64, but maintaining a migration path to /64 in the future, seems to be the best way to get IPv6 rolled out to the edge from a political standpoint. It's easier to make the case to extend IPv6 if you can be fairly certain that it won't cause hosts to suddenly start using IPv6 on their own. I have yet to run into an IPv6 implementation that will use SLAAC with a prefix other than a /64, thankfully. From what I've been told, Cisco is actively working on RA-gaurd for their managed switching platforms, which will be nice to see. Reading a bit of the discussions regarding IPv6 in the Apple world, it seems that they're after supporting DNS server information in RA using RFC 5006. I think RFC 5006 is a very bad idea personally. DHCPv6 was designed to work in harmony with RA, and providing host configuration is beyond the scope of RA. I hope that we don't start seeing implementations of this as it will lead to an environment where some clients support DHCPv6 and some do not. The SLAAC vs. DHCPv6 war all seems a bit silly. They're both tools that are designed to compliment one another, and both have their uses. DHCPv6 does complicate things with the DUID rather than using the physical address, but I can appreciate the problems they're trying to overcome. It just makes this a little more complicated for those of us who would like to maintain associations between a hosts IP and IPv6 information in a dual-stack environment. On Sun, Oct 18, 2009 at 11:45 AM, Kevin Loch kl...@kl.net wrote: Nathan Ward wrote: On 19/10/2009, at 1:10 AM, Owen DeLong wrote: On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: On 18/10/2009, at 11:02 PM, Andy Davidson wrote: On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. Because RA assumes that all routers are created equal. RFC4191 In some cases different devices on a segment need a different default router (for default). This is the fundamental problem with RA's, they shotgun the entire segment. Because RA is harder to filter. DHCP in IPv4 was hard to filter before vendors implemented it, too. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. Security concerns would be useful to explore. Can you expand on this? What would be useful would be having the option to give a default router to a dhcpv6 client, and having vrrpv6 work without RA's. Why can't we have those options in our toolbox in addition to this continuously evolving RA+hacks? - Kevin -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
OT: Any PALM e-mail administrators
I have tried contacting PALM through their listed contact phone numbers and by email to their postmaster, all to no avail. I am having problems with their SMTP servers being unable to communicate with my domain configured SMTP server using Mxed addessing (ie, to kmedc...@dessus.com) although sending directly to the mail server (kmedc...@mail.dessus.com) works correctly. This issue is limited to PALM and their configuration and I cannot duplicate (nor have I ever come across such a misconfiguration anywhere else, ever). Even adding A records directly to the domain record itself does not result in success. I have had no success contacting anyone with clue at palm for about three weeks now despite numerous attempts to do so. Anyone with an internal contact, or if anyone from PALM is here, off-list contact info would be appreciated. (mail sent via PALM SMTP servers will have to be sent to the incorrect -- direct mailbox on the SMTP server -- address kmedc...@mail.dessus.com or your misconfigured servers will not even attempt to send the message). Now, back to our regularly scheduled programming ... -- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
RE: IPv6 Deployment for the LAN
In some cases different devices on a segment need a different default router (for default). This is the fundamental This capability is also defined, more specific routes - but no one encouraged any vendors that I know of to support it - so they don't. Big demand? problem with RA's, they shotgun the entire segment. As opposed to a standard deployment, where the DHCP server provides the same information to every host on that link ... ??? What would be useful would be having the option to give a default router to a dhcpv6 client, and having vrrpv6 work without RA's. These are separate problems. Host configuration vs. first-hop redundancy, and we can solve them independently. Why can't we have those options in our toolbox in addition to this continuously evolving RA+hacks? You say hacks, others see it as relatively-speaking simple additions of more functionality. You can define any options you want for DHCPv6, write a draft and get community support. I don't see how that (continuously evolving DHCPv6 hacks) is any better than what is happening with RAs? I, for one, am just fine with RAs being the first step - leading to either SLAAC or (some mode of) DHCPv6 ... /TJ
Re: {SPAM?} Re: IPv6 Deployment for the LAN
And not just Cisco, IIRC it is an open standard anyone can implement ... ? Here is the work being done on RA-Gaurd: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-03 -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On 18/10/2009 11:05, Nathan Ward wrote: Remember RA does not mean SLAAC, it just means RA. This is not ideal because two protocols are being mandated instead of just one: RA for client-side autoconfiguration and DHCPv6 for everything else. This is pointless. We have a good working model in ipv4: namely, the Joesoap in charge of the LAN decides what addressing parameters are to be used on the network, and it all uses a single protocol: dhcpv4. you can filter it out from rogue clients using dhcp-guard on a decent switch, and everyone is happy with it. However, in IPv6, we are being told that this is not good enough: that there need to be two protocols, one of which tells the client enough information about the network so that the client can choose its own address, route packets but not enough to allow DNS (i.e. functional internet connectivity). So then we decided that we needed another protocol to give the client everything else that it needed. And in order to avoid egos from tripping over other egos, each camp kept on their own turf: dhcp6 was hobbled to the extent that it couldn't feasibly be called a host configuration protocol (no default route, no address assignment and no subnet size options), and the RA folks at least initially tried to keep useful functionality out of the RA spec. Or at least this was the plan. Of course, it was a completely broken plan for a variety of reasons, including: - there were two protocols required for stateless network management instead of one - we already had a really good working model in ipv4 - address selection was performed by the client, not the administrator - we found out in the early 1990s with RIP that you need to be careful about announcing default routes, and because you now have to protect against two protocols instead of just one, this makes things more difficult - no-one thought it might be useful to ask the operators what they thought about using two protocols instead of one. Did it ever occur to the people defining the standards that most LAN operators are not particularly smart people, and that they would have trouble with this? So, as a result, RA grew about 6 arms and 8 legs (most of them the left-side variant), and the DHCPv6 camp continued with their diplomatic tip-toeing around the RA camp until one day, someone threw King Looie Katz's tail into the dirt: no longer were Hooie, Fooie or Kooie Katz going to play nice! So, now we have protocol proposals in the pipeline that will enable DHCPv6 to be sufficient to functionally run stateless address configuration rather than to continue to be nothing more than a necessary headache. Hooray! Of course, there are still several people in ietf-land who think that this is all a terrible mistake, and that RA and DHCPv6 should have been complementary to each other. To these people, I will be happy to listen to their opinions on condition that they do two things: 1) agree to filter out all ethertypes except 0x86dd on their laptops at ietf meetings (and spare me the platitudes that they aren't responsible for what the vendors implement) and 2) attempt to run a large IPv6 multi-lan network with current operating systems and switching gear for a period of one month. Most seriously, there's not nearly enough eating-one's-own-dog-food going on here. So, if someone in protocol standards-land had actually asked the operators what they wanted, they would have been told that they needed a protocol which took decisions about addressing and configuration away from the client. You plonk your computer on a lan, and you are told what address to use and what configuration parameters to use. You don't start inventing your own, because honestly, it's a pain to manage. I appreciate there are conflicting views on this particular point; I've heard the arguments and remain entirely unconvinced that RA + anything makes for a better stateless host configuration protocol than dhcpv6 will, or ought to have from day one. Meanwhile, because of all this pointless bickering about whether dhcpv6 should have had this or that or the other option, we're 13 years down the road since ipv6 was defined and we still don't have what I would consider to be a sane and fully standardised host auto-configuration model. I find it amusing that sane autoconfiguration was supposed to be one of the primary selling points of ipv6 in the first place. Nick
Re: IPv6 Deployment for the LAN
TJ wrote: In some cases different devices on a segment need a different default router (for default). This is the fundamental This capability is also defined, more specific routes - but no one encouraged any vendors that I know of to support it - so they don't. Big demand? by Default I meant 0.0.0.0/0, not more specifics. problem with RA's, they shotgun the entire segment. As opposed to a standard deployment, where the DHCP server provides the same information to every host on that link ... ??? Not always. The DHCP server can be aware of specific clients by mac address and give different options (and even pseudo-static IPs). DHCP server is not always running on a router so adding this functionality to routers won't help. - Kevin
RE: IPv6 Deployment for the LAN
Remember RA does not mean SLAAC, it just means RA. This is not ideal because two protocols are being mandated instead of just one: RA for client-side autoconfiguration and DHCPv6 for everything else. Um, DHCPv6 does configure the client - perhaps not until the +M or +O option is recieved. This is pointless. We have a good working model in ipv4: namely, the Joesoap in charge of the LAN decides what addressing parameters are to be used on the network, and it all uses a single protocol: dhcpv4. You can filter it out from rogue clients using dhcp-guard on a decent switch, and everyone is happy with it. And RA Guard will fix it for IPv6. Did we have DHCP Guard @ day 1? However, in IPv6, we are being told that this is not good enough: that there need to be two protocols, one of which tells the client enough information about the network so that the client can choose its own address, route packets but not enough to allow DNS (i.e. functional internet connectivity). So then we decided that we needed another protocol to give the client everything else that it needed. And in order to avoid egos from tripping over other egos, each camp kept on their own turf: dhcp6 was hobbled to the extent that it couldn't feasibly be called a host configuration protocol (no default route, no address assignment and no Incorrect, DHCPv6 can assign addresses. subnet size options), and the RA folks at least initially tried to keep useful functionality out of the RA spec. Or at least this was the plan. Of course, it was a completely broken plan for a variety of reasons, including: - there were two protocols required for stateless network management instead of one - we already had a really good working model in ipv4 Perhaps, But I submit that good and working do not mean ideal. - address selection was performed by the client, not the administrator If SLAAC is chosen, yes. - we found out in the early 1990s with RIP that you need to be careful about announcing default routes, and because you now have to protect against two protocols instead of just one, this makes things more difficult - no-one thought it might be useful to ask the operators what they thought about using two protocols instead of one. Did it ever occur to the people defining the standards that most LAN operators are not particularly smart people, and that they would have trouble with this? With the addition of RFC5006, you can actually choose just one (once hosts implement it). Just not the one you seem to favor. So, as a result, RA grew about 6 arms and 8 legs (most of them the left-side variant), and the DHCPv6 camp continued with their diplomatic tip-toeing around the RA camp until one day, someone threw King Looie Katz's tail into the dirt: no longer were Hooie, Fooie or Kooie Katz going to play nice! So, now we have protocol proposals in the pipeline that will enable DHCPv6 to be sufficient to functionally run stateless address configuration rather than to continue to be nothing more than a necessary headache. Hooray! And I am OK with all that as well, although THAT also complicates scenarios for implementers. (Now hosts will need to support two discrete host-configuration protocols that actively step on each others' capabilities). Of course, there are still several people in ietf-land who think that this is all a terrible mistake, and that RA and DHCPv6 should have been complementary to each other. To these people, I will be happy to listen to their opinions on condition that they do two things: 1) agree to filter out all ethertypes except 0x86dd on their laptops at ietf meetings (and spare me the platitudes that they aren't responsible for what the vendors implement) and 2) attempt to run a large IPv6 multi-lan network with current operating systems and switching gear for a period of one month. I'll filter all non-0x86dd if you filter all non-0x800. And I will be more successful as you are then blocking ARP :). The other missing piece of that is most of us aren't going IPv6 ONLY just yet - so if we need to rely on IPv4 for a bit longer that is, while far from optimal, atleast kinda OK. (e.g. - cheating off of IPv4 for DNS). Most seriously, there's not nearly enough eating-one's-own-dog-food going on here. Totally agree there! So, if someone in protocol standards-land had actually asked the operators what they wanted, they would have been told that they needed a protocol which took decisions about addressing and configuration away from the client. You plonk your computer on a lan, and you are told what address to use and what configuration parameters to use. You don't start inventing your own, because honestly, it's a pain to manage. It is still the router, a piece of managed infrastructure sending out the information - not like we are encouraging hosts to make up their own prefix info here ... and hosts choosing the low-order bits shouldn't
Re: IPv6 Deployment for the LAN
Thought this off-list reply would be of interest to many here: On Sun, Oct 18, 2009 at 1:43 PM, Daniel G. Kluge wrote: Hello Ray, on the Subject on DHCPv6 for MacOS, there were some discussions on the IPv6-dev lists on Apple, with the usual comment from Apple engineers, that they are not authorized to discuss plans on product features. If you have a substantial MacOS population, I'd recommend to join the discussion, and chime in for support of DHCPv6 on MacOS. The two recent threads on DHCPv6 are: http://lists.apple.com/archives/Ipv6-dev/2009/Sep/msg00018.html http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg3.html The first one is from the perspective of service providers, the latter one from the perspective of enterprises and educational networks Cheers, -daniel I'd like to urge everyone to send in bug reports to Apple as described in the mailing list posts above requesting DHCPv6 in OS X. Thank you, Dan. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
TJ wrote: It is still the router, a piece of managed infrastructure sending out the information - not like we are encouraging hosts to make up their own prefix info here ... and hosts choosing the low-order bits shouldn't matter that much. But that's the fatal flaw of autoconfiguration. Hosts chosing the low-order bits works great until either A) one of those hosts wants a semi-permanent name lodged in a DNS server and the IT guy wants to semi-permanently assign an IP address to it without having to touch the host configuration or B) the RIAA/MPAA/FBI/etc. comes and asks to see the logs which show which user on the subnet had a particular address and then goes to the local court and claims that you're using this newfangled protocol so as to avoid making information available that has always been available before. If *both* of these problems were fixed as well as DHCP fixes them for IPv4, there'd be a whole lot more support for letting the hosts choose their low-order bits. Matthew Kaufman
Re: IPv6 Deployment for the LAN
On Oct 17, 2009, at 8:55 PM, Ray Soucy wrote: Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. ... My question is this: what are your goals? What are you trying to achieve? Force all authorized machines to register? If so, why? We'll leave out for now whether or not there's even much point to that. My university -- and I'm just a user of campus computing facilities; I don't run them -- has concluded that there's no particular benefit to requiring registration or permission; it's one more server complex to run, one more database to maintain, and one more thing to break, and the benefits don't seem to be worth the cost. And given that we've had incidents of IP and MAC address spoofing, where it took the switch logs to figure out what was going on, I'm very far from convinced that registration is of any benefit anyway. In other words -- yes, I agree with the campus policy -- but that's not the question I'm asking. I ask because there may be other ways to achieve your actual goal, but without knowing that it's hard to make recommendations. The most obvious answer is accountability, but physical port number may be a better approach there, depending on how the campus network is run. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: IPv6 Deployment for the LAN
Thanks for the response, if only to force me put my thoughts down into words. On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin s...@cs.columbia.edu wrote: ... My question is this: what are your goals? What are you trying to achieve? Force all authorized machines to register? If so, why? We'll leave out for now whether or not there's even much point to that. My university -- and I'm just a user of campus computing facilities; I don't run them -- has concluded that there's no particular benefit to requiring registration or permission; it's one more server complex to run, one more database to maintain, and one more thing to break, and the benefits don't seem to be worth the cost. And given that we've had incidents of IP and MAC address spoofing, where it took the switch logs to figure out what was going on, I'm very far from convinced that registration is of any benefit anyway. In other words -- yes, I agree with the campus policy -- but that's not the question I'm asking. Not my place to implement policy; I'm not a lawyer. We already have monitoring in place for accountability that maps each address used on a network (regardless of IP or IPv6) to a device and interface for incident response. The greater concern is that SLAAC makes IPv6 available to hosts that may not be prepared for it. If administrators are asked if they would like IPv6 enabled, having been explained the implications of such if SLAAC is used for configuration, the majority of the time they come back and say thanks, but no thanks. In this situation, SLAAC is holding back deployment of IPv6. I suspect other have seen this as well. Part of the problem here is that IPv6 isn't new; it's old. Implementations have been in place for years on certain systems without proper testing as they have gone largely unused. We've seen cases where older versions of Linux can be crashed by enabling SLAAC on a network being one example. By using DHCPv6 we gain some advantages: We can automatically update DNS for hosts so that IPv4 records and IPv6 records match; We have the ability to roll out DHCPv6 on a per-host basis without causing problems on the production IP network; and we can roll it in to our existing [home grown] tools for network management in a way that is easy for users of the system to understand (keep in mind, we provide tools to delegate network control to hundreds of sub-administrators throughout the State). The original question here wasn't SLAAC vs. DHCPv6. I think many network operators here who are tasked with managing anything of scale will agree that SLAAC doesn't quite cut it and is often a step backwards. The overhead of implementing and administering such a system at this scale generally wins out over not doing so. The question I was mainly concerned with was if anyone has encountered issues with the use of an 80-bit prefix to prevent SLAAC from being active. While the prefix advertisement does have the autonomous flag which can be set to false, the underlying problem of IPv6 implementations not being consistent across hosts operating systems yet doesn't change. I'm not convinced that there aren't implementations out there that will enable SLAAC regardless of what the prefix flag is set to, so using a prefix other than a 64 provides an easy way to [attempt to] avoid this, all the while allowing for us to eventually migrate to a 64-bit prefix when host support improves. Another concern is that we certainly don't want to use SLAAC for servers, and I'm hesitant to promote the use of manual IP configuration as it can quickly become a nightmare if you need to move networks (admittedly there should be less need for network moves, but all the same). DHCP has long solved many of these issues in the IP world, and it is perfectly reasonable, and desirable, to apply them to IPv6 though the use of DHCPv6. Perhaps in the future, as we see less legacy hosts online we'll be in a position to make use of both SLAAC and DHCPv6 for host configuration, but in all honesty, once DHCPv6 is in place, why would you want to use SLAAC? My other question was DHCPv6 support from Apple (who seems to be one of the few in resistance of DHCPv6). This list managed to point me in the right direction to nag them about it. I ask because there may be other ways to achieve your actual goal, but without knowing that it's hard to make recommendations. The most obvious answer is accountability, but physical port number may be a better approach there, depending on how the campus network is run. --Steve Bellovin, http://www.cs.columbia.edu/~smb -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
2009.10.18 NANOG47 Community Meeting notes
Here's my notes from tonight's Community Meeting from NANOG47. Short and sweet, for those who couldn't attend in person. :) Matt 2009.10.18 NANOG 47 community meeting notes NOTES: Joe Provo calls the meeting to order at 1740 hours Eastern Time. Welcome to Dearborn, haven't been here since NANOG 13. Hotel is very, very different. Thanks for coming to the community meeting, and caring enough to show up. AGENDA: Steering Committee Report--Joe Provo Program Committee Report--Dave Meyer Mailing List Committee Report--Kris Foster Marketing Working Group Report--Patrick Gilmore Merit Report--Betty Burke This is an election meeting, later on in the session we'll have candidates for SC come up to speak for a few minutes. The mics are live, they want a dialog, not a lecture. Steering committee members have blue badges. Betty Burke Steve Feldman Kris Foster Patrick. W. Gilmore, etc. Highlights since NANOG 46 elusive network experiment policy reached fruition annual Postel scholarship was awarded (could use additional funding to allow it to continue) Operator of Tomorrow partnership Preparation for this meeting Work on future meetings. Austin, San Francisco, Atlanta finalized and published--next three are in the pipeline Elections--why this is so brief! SC candidates will have a few minutes each here during the Elections portion SC and charter ballot voting is open So are PC and MLC nominations. Get your nominations in now, if you know people who can help contribute. nominati...@nanog.org program committee--Dave Meyer review process -- 47 talks, 80 submitted. People submit great ideas, but never submit slides or even outline slides. Program committee openings questions for us? If you know people who would be good for the PC, please nominate them; it takes some amount of time committment, but it's an essential part of making the meetings happen. They try to rate the talks based on what is submitted, but at times, the material submitted is very light, and the final slides don't arrive until very late. They had submissions that weren't complete; why not turn them into lightning talks? That's generally what they do with the short/incomplete ones. Louie--of the people who submitted good topics, they might not want to do the work until they know their outline was accepted... They are notified that their talk has been accepted so they can work on it. Ren notes that sometimes they get similar topics, so they might try to get the two sets of people to work together. Todd Underwood, for context, he'll note that it's a standoff--really good presenters playing chicken with the program committee. If the narrative of the story isn't in the slides, nobody who doesn't know you will understand it from just the slides; you'll need to give some idea of the narrative along with the slides. And the archives are hugely important; make sure the presentation tells the story even if you aren't presenting it. Josh, Rodney, Lane, Todd, and others have done a great job over the years supporting the meetings and reading through Joel Jaeggli, outgoing PC member...the people leaving have generally been around for 2 years. They've been around since the new charter was instituited. Procedures within the PC remain adhoc but not arbitrary reliance on precedent willingness on the part of participants to routinely alter the division of labour responsive to SC input, but not beholden to them (within limits) Transparency The minutes are out there, but nobody but Martin Hannigan reads them...and he stands up to say even he doesn't do that anymore. Points of Friction over the past few years. EArlier availability of agenda: means CFP is earlier, ability to respond to industry events is more constrained, etc. programming of joint activities ARIN SC Distributing ownership of repeating program elements and increasing depth of the bench inclusivenes new program elements. Big Wins Lightning Talks more breadth in presentations now Peering track better representation from more people Newcomers (Ren) Program quality MLC members Randy Epstein Steve Feldman -- SC liason Kris Foster -- Chair Sue Joiner -- Merit Appointee Simon Lyall Updates Policies were updated in August to reflect the thread moderation policy http://www.nanog.org/mailinglist/warningpolicy.php If you have questions/issues with it, raise them on nanog-futures mailing list. Very light since last meeting. A few thread moderations, but not many. 10,448 subscribers currently on the list. Volunteers needed Kris Foster and Simon Lyall's terms are ending Possibly a third seat opening up depending on what gets decided later. If you don't subscribe, read, or post, please tell us why! Marketing Working Group Report -- Patrick What is it? Email updates are sent to NANOG-futures Idea is to raise more money to reduce costs. Need a new chair! New ideas for NANOG 47 and onward Party Promotion party on agenda, tickets handed out at registration
Re: OT: Any PALM e-mail administrators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Keith! On Sun, 18 Oct 2009, Keith Medcalf wrote: I have tried contacting PALM through their listed contact phone numbers and by email to their postmaster, all to no avail. Contact me off list. I have been working this problem for over a month and have some contact info. RGDS GARY - --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFK25+xBmnRqz71OvMRAuyxAKDQ6bKTNL82vgLGwHt2/lsgMCEcAQCg3fhB n2IDndq+ek32I+dyFUISjJc= =sDjJ -END PGP SIGNATURE-
Re: IPv6 Deployment for the LAN
On Sun, Oct 18, 2009 at 01:29:54PM -0400, TJ wrote: You say hacks, others see it as relatively-speaking simple additions of more functionality. You can define any options you want for DHCPv6, write a draft and get community support. I don't see how that (continuously evolving DHCPv6 hacks) is any better than what is happening with RAs? The difference is that I don't have to wait for my switch/router vendor to implement RA extensions, I can just implement it myself in an open source DHCPv6 server. Software that is embedded in hardware is very hard to get changed.
