On 18/10/2009, at 2:28 PM, William Herrin wrote:

On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy <rps@maine.edu> wrote:

...

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.

Ray,

Common wisdom says that?

...

Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6.

I thought someone had to respond to router solicitations for stateless autoconfig of global scope addresses to happen. On Linux you just don't run the radvd. On Cisco I think it's something like "ipv6 nd suppress-ra" in the interface config. Does that fail to prevent stateless autoconfig? Or is there a problem with the operation of DHCPv6 if router advertisements aren't happening from the router?

RA is generally required whether you use stateless or stateful autoconfiguration. You have to tell the hosts to send a DHCPv6 DISCOVER message by turning on the managed flag in the RA. RA does not mean that SLAAC happens. Ray, do you have examples of hosts or stacks that ignore AdvAutonomousFlag? -- Nathan Ward

On Sun, 18 Oct 2009 09:03:12 +0100 Andy Davidson <andy@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 1700 www.netsumo.com NetSumo Specialist ISP/networks consultancy, Whitelabel 24/7 NOC

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 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:cra@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.

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." 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:owen@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

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

I notice that Cisco has a "prefix no-autoconfig" statement in some

Yes, advertise it as on-link but not suitable for autoconfig. You would want to do this (along with the M & O bits) for a stateful-DHCPv6 segment ...

...

From what I've been told, Cisco is actively working on RA-gaurd for their managed switching platforms, which will be nice to see.

And not just Cisco, IIRC it is an open standard anyone can implement ... ?

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.

++1 (And if I could vote "yes" on that statement more than once on that I would ...) /TJ

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

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.

...

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 matter that much.

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.

Well, obviously not _fully_ standardized as we are still adding stuff ... but I would argue the sanity part is OK. And again, it still (esthetically and architecturally) seems to make a lot of sense for the router to send out information about the router. With the added bonus of "it can and does work today", regardless of the arguments for/against it. /TJ

"> 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:andy@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

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

Iljitsch, On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote:

On 18 okt 2009, at 10:03, Andy Davidson wrote:

...

Support default-routing options for DHCPv6 ! This would be a big mistake. [...] It's time for this DHC stuff to reach its final resting place.

I'm curious: are you anticipating IPv4 network operators are willing/interested/planning on redesigning/rebuilding their entire provisioning and backend systems in order to support IPv6? Regards, -drc

Once upon a time, Iljitsch van Beijnum <iljitsch@muada.com> said:

What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration.

You want to invent yet _another_ form of configuration management? -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

What we have now is not a mess. What we have is a solid base to build on. The problem is in education, the fact that both stateless and stateful configuration are valid components to IPv6 for example, and proper implementation by vendors. There are a few challenges with IPv6 that need to be worked out, like RA-gaurd and DHCPv6 snooping, for example, but the core of IPv6 was generally done right. Reading this thread can get rather frustrating, what I've gotten out of the most recent exchange is that the combined suggestion is to add DNS to RA, and to add gateway information to DHCPv6. Well, DHCPv6 already handles DNS quite nicely (and DHCPv6 is about more than just DNS mind you), and RA does a perfect job handling gateway selection. I would love to understand how you feel that the roles of RA and DHCPv6 should be swapped. On Wed, Oct 21, 2009 at 4:33 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

On 21 okt 2009, at 22:23, Chris Adams wrote:

...

...

What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration.

...

You want to invent yet _another_ form of configuration management?

Short answer: no, life is too short and I have other problems that need solving.

Long answer: what we have now is a mess, if we want to clean up the mess we have to get it right, and putting new options in binary protocols is not right in any way, shape or form.

-- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/

----- Original Message ----

From: Iljitsch van Beijnum iljitsch@muada.com Then again, if we remove all the improvements from IPv6 what's the point of adopting it?

How about "IPv4 address depletion?" I'm perfectly happy with how my network works.  I do, however, want it to keep growing, and this requires more addresses.   The requirement for organizations with thousands (or in some cases millions) of deployed customers to dramatically change how they can associate an IP address with customer ports (or provide remote configuration of said customers' devices) is not an attractive feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com

On 21 okt 2009, at 21:55, Owen DeLong wrote:

However, making it available as an option in DHCPv6 allows the end- user/operator to choose the technology that fits their needs best. I do not know why you are so determined to prevent this choice at the operator level.

For the same reason that we don't let the kids play with the powertools: giving them what they want here just makes everything end in tears. If people want to run DHCPv6, fine, we're all adults. If they want to go to the IETF and fix what's wrong with DHCPv6, so much the better. But taking the information from the place where we can make sure it's correct and putting it in a place where we can only guess so we break the network regularly is A VERY BAD IDEA.

On 21 okt 2009, at 22:48, Owen DeLong wrote:

The assumption that the router "knows" it is correct for every host on a given LAN simply does not map to reality deployed today.

What I'm saying is that a router knows whether it's a router or not. A DHCP server does not, so it has to make a leap of faith and then sometimes the hosts fall flat on their face if there's no router on the address indicated by the DHCP server. The counter-argument is "it works today" but my counter-counter-argument is "it doesn't work today". I get burned by broken DHCP setups _all_ _the_ _time_ at work, at IETF meetings, at RIPE meetings, etc. Anyone claiming that having a DHCP server direct hosts to a router address in the blind is simply incompetetent, so there is no point in listening to them. If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.

Please explain to me how I can achieve this functionality in RA/SLAAC or stop pushing to prevent it from being available in DHCPv6.

There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways.

Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated.

Stop trying to break the internet and I'll treat you like an adult.

On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:

On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:

...

If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.

The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network.

I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange.

Regards, K.

--bill

On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote:

On Thu, 2009-10-22 at 10:30 +0000, bmanning@vacation.karoshi.com wrote:

...

...

The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network.

I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange.

And how do they discriminate now, with IPv4?

Regards, K.

IPv4 has no concept of RA/ND. to make this construct work at all in IPv6, all participants have to turn -off- RA/ND to prevent one or more routers trying to impose their views of addressing on their neighbours. --bill

On Thu, Oct 22, 2009 at 10:18:48PM +1100, Karl Auer wrote:

On Thu, 2009-10-22 at 11:08 +0000, bmanning@vacation.karoshi.com wrote:

...

On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote:

...

On Thu, 2009-10-22 at 10:30 +0000, bmanning@vacation.karoshi.com wrote:

...

...

The RA contains a preference level... maybe that doesn't cut it if

I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange.

And how do they discriminate now, with IPv4?

IPv4 has no concept of RA/ND. to make this construct work at all in IPv6, all participants have to turn -off- RA/ND to prevent one or more routers trying to impose their views of addressing on their neighbours.

But my question was not about IPv6. How do IPv4 routers operate in such a situation?

Regards, K.

exchange design 101. each connecting router interface is manually configured with an address of the exchange fabrics IP space. to establish peering, a router needs to know, at a minimum, the targets IP address and ASN - and while arp (if enabled) can get the target IP address, the ASN has to come via another channel - usually manually aquired. this is how the exchanges generally work, regardless of IP address family. more generally, where there are two or more egress routers from a broadcast domain, there will be problems -if- the routers know about each other -and- have the ability to try and set the exit rules for all other participants sharing the broadcast domain. Hence, with IPv6 and RA/ND, the idea of "preference" levels ... although in most cases I've experienced where there are multiple exit routers - that doesn't work either, since only subsets of the nodes on the shared media can use one or the other egress router. e.g. all the nodes don't fate-share. RA/ND was only an 80% solution anyway. --bill

On 22/10/2009 11:30, bmanning@vacation.karoshi.com wrote:

On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:

...

The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network.

I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange.

Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance to an IXP? Being one of these "artefact" operators - and clearly stuck with a very small dinosaur brain - I am having some trouble understanding the point you're attempting to make here. Nick

On 22/10/2009 12:49, bmanning@vacation.karoshi.com wrote:

its been a few weeks/years/minutes since I ran an exchange fabric, but when we first turned up IPv6 - the first thing they did was try to hand all the other routers IPv6 addresses. that pesky RA/ND thing... had to turn it off ... RA preference would not work, since there was no -pecking- order - all the routers were peers.

Bill, I am not able to look at this paragraph without being reminded of Charles Babbage's take on the GIGO principal: "On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." Nick

On Thu, 22 Oct 2009, bmanning@vacation.karoshi.com wrote:

On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:

...

On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:

...

If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.

The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network.

I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange.

And you want to use router advertisments for assigning addresses for them? Huh! Regards, Janos

On Thu, 22 Oct 2009 21:20:11 +1100 Karl Auer <kauer@biplane.com.au> wrote:

On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:

...

If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.

The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network.

IPv6 Subnets/VLANs are pretty cheap, maybe if people are having this issue, that's a sign they need to divide their hosts into more subnets/VLANs. More broadly, it seems the argument is where to put networking operational policy - in the network (via e.g. engineered topology), or on the hosts. I think there is value in putting it in the network, because it avoids having to change host located policy when the network policy changes.

In any case, anywhere this is actually of vital importance, a routing protocol would be in use.

Using the DHCP protocol to deliver information - about anything really - is what it's *for*. That said, making clients depend utterly on the presence of a working DHCP server for basic connectivity seems like a backward step. Of course, different people have different ideas about what constitutes "basic" connectivity.

...

Stop trying to break the internet and I'll treat you like an adult.

Whoa! Tell you what, how about if I break it, and you get to choose which piece you keep? [Bash, bash, thud. Ugh. Hm. It's tougher than it looks!]

:-)

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

Iljitsch van Beijnum wrote:

If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.

In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see.

There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways.

Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap.

...

Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated.

Stop trying to break the internet and I'll treat you like an adult.

At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work. How do we fix that? - Kevin

David Conrad wrote:

...

Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap.

Right. I'll admit some confusion here. If the IETF, due to religion or aesthetics, is blocking attempts at making DHCPv6 do what network operators _need_ (as opposed to want), why haven't network operators routed around the problem and gone and funded folks like ISC, NLNetLabs, Cisco, Juniper, et al., to implement what they need?

...

At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work.

How do we fix that?

You seem to be asking "how do we make people not stupid". Folks tend to simplify reality so that it fits their world view. Stupid people attempt to force that simplified reality onto others. You can either play their game, attempting to get them to understand reality is often more complicated than we'd like, or route around them. Or you can post to NANOG... :-)

The root of the argument I see in this entire thread is the assumption that 'what we have for IPv4 has *always* been there'. There is lots of finger pointing at the IETF for failure to define 15 years ago, what we have evolved as the every-day assumptions about the IPv4 network of today. SLAAC was presented specifically to deal with the DHCP failure modes of the time, and the very real possibility that DHCP might not make it as a technology that operators would want to deploy. While lots of evolution happened in the DHCP space to deal with changing operational requirements, it is still a complex approach (which may be why it is favored by those that like to maintain a high salary). To be fair, there were failures in the IETF, as the SLAAC and DCHP sides couldn't get out of each other's way; so now instead of having 2 independent models for provisioning, we have 2 interdependent models. RFC 5006 is one step at breaking that interdependence, and more are needed on the DHCPv6 side, yet these steps can't happen if people sit in the corner and do the 'they won't listen to me' routine. For those that insist that DHCP is 'the only way to know who is using an address', have you considered dDNS? Oh wait, that moves the trust point to a different service that in the enterprise is typically run by the host admin, not the network admin, or in the SP case crosses the trust boundary in the wrong direction ... my bad. Seriously, there are ways to figure this out, as Ron Broersma pointed out on Monday. I am not arguing for one model over the other, as they each have their benefits and trade-offs. The real issue here is that some people are so locked into one approach that they refuse to even consider that there might be an alternative way to achieve the same goal, or that the actual goal will change over time in the face of external requirements. IPv4 continues to be a work-in-progress 30 years later, and IPv6 will be no different. The fact that there is not functional parity between the operational aspects is due to operators insisting until very recently that 'the only thing that matters is IPv4'. It should not be a surprise that IPv4 is where the majority of the work in the IETF happened. Despite my attempts to get the IETF to stop wasting effort on what is clearly a dead-end, this is still true today. As drc points out, you can continue to post complaints on the nanog list, or if you want real change make sure your vendors get a clear message about IPv6 being the priority, then make your point on the appropriate IETF WG list. At the end of the day, the way networks are operated today is not the way they will be operated in 5 years, just as it is not the same as they way they were operated 5 year ago. Asserting a snap-shot perspective about 'requirements' has its place, but everyone needs to recognize that this is an evolving environment. Changing the base protocol version is just one more step on that evolutionary path. Tony

On 22 okt 2009, at 17:03, Kevin Loch wrote:

...

If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.

In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see.

Lots of people "need" a gun. If I were living in a place where bears walk around loose I might "need" one, too. But most guns are used to shoot the owner in the foot most of the time. The world would be a better place without them. Like I said, if there's a bunch of routers announcing their presence and you want a DHCP option to provide guidance to a host as to which one to choose, that would be fine. But pointing to a potentially non- existing address in the hopes that there will magically be a router residing at that address would a serious regression in robustness.

...

There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways.

Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility.

What does that have to with anything? IPv6 stateless autoconfig predates the widespread use of DHCPv4.

Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap.

Absolutely not. Give users the choice between something good that suits their needs 83% and a piece of crap tht suits their needs 84% and they'll choose the latter each and every time. Users get to say what they need. They don't get to design the solution by committee any more than they get to design bridges or airplanes by committee, although of course they do get to choose which ones to use.

At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work.

How do we fix that?

Tell the IETF your real requirements, don't try to do back seat protocol design. Protocol design is hard, the IETF gets it wrong most of the time (and they do better than some of their colleagues, still). Suggesting specific changes to a protocol as a solution to an unstated real requirement wastes everyone's time. With writing, they tell you "listen when people say there is a problem, but ignore them when they tell you what the problem is". Same thing here. Users know their needs, but generally they don't know the best way to meet those needs.

On Oct 22, 2009, at 8:44 AM, Iljitsch van Beijnum wrote:

On 22 okt 2009, at 17:03, Kevin Loch wrote:

...

...

If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.

...

In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see.

Lots of people "need" a gun. If I were living in a place where bears walk around loose I might "need" one, too. But most guns are used to shoot the owner in the foot most of the time. The world would be a better place without them.

As a strong proponent of the second amendment, it is now clear to me that we have a fundamental disagreement on how society should interoperate which is unlikely to ever be resolved between us.

Like I said, if there's a bunch of routers announcing their presence and you want a DHCP option to provide guidance to a host as to which one to choose, that would be fine. But pointing to a potentially non- existing address in the hopes that there will magically be a router residing at that address would a serious regression in robustness.

It really isn't a serious regression in robustness in the real world. It really is functioning today. Most DHCP servers are not used to shoot users in the head, despite your claims to the contrary.

...

...

There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways.

...

Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility.

What does that have to with anything? IPv6 stateless autoconfig predates the widespread use of DHCPv4.

Hmmm... Perhaps you should be asking yourself why IPv6 SLAAC was not used as the model for address assignment in IPv4 instead of DHCPv4 in that case?

...

Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap.

Absolutely not. Give users the choice between something good that suits their needs 83% and a piece of crap tht suits their needs 84% and they'll choose the latter each and every time.

Yes... As well they should. Meeting their needs 84% of the time is actually vastly superior.

Users get to say what they need. They don't get to design the solution by committee any more than they get to design bridges or airplanes by committee, although of course they do get to choose which ones to use.

Depends on how you define users. If you don't think that airlines have a substantial amount of technical input into how airliners are designed, you are vastly mistaken.

...

At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work.

...

How do we fix that?

Tell the IETF your real requirements, don't try to do back seat protocol design. Protocol design is hard, the IETF gets it wrong most of the time (and they do better than some of their colleagues, still). Suggesting specific changes to a protocol as a solution to an unstated real requirement wastes everyone's time.

With writing, they tell you "listen when people say there is a problem, but ignore them when they tell you what the problem is". Same thing here. Users know their needs, but generally they don't know the best way to meet those needs.

OK... Here's the real requirement: Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to: 1. Default Router 2. DNS Resolver information 3. Host can provide name to server so server can supply dynamic DNS update 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) 5. NTP servers 6. Boot server 7. Site specific attribute/value pairs (ala DHCPv4 Options) These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured. Owen

This to me is one of the least credible claims of the RA/SLAAC crowd. On the one hand we have carriers around the world with millions and millions of customers getting default routes and other config through DHCPv4 every day. And most of the time it actually works very well!

On the other hand we have RA/SLAAC with a vastly smaller customer base, vastly less real life testing - but which is still claimed to be so much better that DHCPv6 is not *allowed* to get a default route option.

If the argument against RA being used to provide gateway information is "rogue RA," then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? I guess I'm not really seeing the case here. Are people really making use of DHCP to provide hosts on the same network with different default gateway information? If so, why? Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a good idea and it works. You can add options to DHCPv6, but I don't see many vendors implementing default gateway support unless you can make a real case for it. My fear is that your goal is to do away with RA completely and turn to DHCPv6 for all configuration. RA is actually quite nice. You really need to stop fighting it, because it's not going away. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/

Sorry, not buying it. The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA. What your proposing as a solution isn't much of a solution at all but just a (seemingly) lesser problem. On Thu, Oct 22, 2009 at 3:29 PM, Leo Bicknell <bicknell@ufp.org> wrote:

In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote:

...

If the argument against RA being used to provide gateway information is "rogue RA," then announcing gateway information though the use of DHCPv6 doesn't solve anything.  Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6.  So what is gained?

It's a huge difference, and any conference network shows it.

Let's assume 400 people come into a room, get up and working (with DHCPv4, and IPv6 RA's).

Someone now introduces a rogue IPv4 server.  Who breaks?  Anyone who requests a new lease.  That is 400 people keep working just fine.

Now, someone introduces a roge RA.  Who breaks?  All 400 users are instantly down.

More importantly, there is another class of misconfigured device.  I plugged in a Cisco router to download new code to it on our office network.  It had a DHCP forward statement, and IPv6.  It was from another site.

The DHCP forward didn't work, it pointed to something non-existant that also was never configured for the local subnet.  There was zero chance of IPv4 interfearance.

The IPv6 network picked up the RA to a router with no routes though, and so simply plugging in the old router took down the entire office network.

The operational threats of a DHCP based network and a RA based network are quite different.  Try it on your own network.

--       Leo Bicknell - bicknell@ufp.org - CCIE 3440        PGP keys at http://www.ufp.org/~bicknell/

-- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/

Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. On Thu, Oct 22, 2009 at 3:50 PM, Leo Bicknell <bicknell@ufp.org> wrote:

In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote:

...

The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA.

Port based solutions don't work well on wireless networks and other mediums.

--       Leo Bicknell - bicknell@ufp.org - CCIE 3440        PGP keys at http://www.ufp.org/~bicknell/

-- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/

Correct. Not sure if you got the sarcasm in that last reply... As far as I'm concerned, a rogue is a rogue. Knowing about it the instant it happens might even be better than slowly coming to the realization that you're dealing with one. The point is that we need to address rogues regardless of their type, not move from RA to DHCPv6 because the impact of a rogue is slower to disrupt service. On Thu, Oct 22, 2009 at 4:06 PM, Chuck Anderson <cra@wpi.edu> wrote:

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:

...

Really.  How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA.

Rogue DHCP doesn't immedately take down the entire subnet of machines with existing DHCP leases.  It generally only affects new machines trying to get a lease, or RENEWing machines.  The impact of a rogue RA is to immediately break connectivity for every machine on the subnet. Differing impacts leads to different risk assessments of which protocol to use.

Regardless, modern wireless deployments use central controllers or smart APs that can filter DHCP.  They could be extended to filter RA as well.

And this whole point is rather moot because we have RAs and must deal with them.  It is too late to get rid of the RA behavior of clients. Even if you don't want to use RAs, your hosts are going to still listen to them which means a Rogue RA is going to take down your network.  We have this problem even on IPv4-only subnets, where a Rogue RA (usually a Windows box with routing turned on) breaks connectivity to dual-stack servers for machines on that subnet.  Since the hosts prefer native IPv6 connectivity over IPv4, the hosts end up preferring the Rogue RA as the route towards the dual-stack server.

We really just need to bug our vendors to implement Rogue RA protection for wired and wireless ASAP, wherever we are in our deployment of IPv6.

-- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/

On 22/10/09 16:06 -0400, Chuck Anderson wrote:

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:

...

Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA.

Rogue DHCP doesn't immedately take down the entire subnet of machines with existing DHCP leases. It generally only affects new machines trying to get a lease, or RENEWing machines. The impact of a rogue RA is to immediately break connectivity for every machine on the subnet. Differing impacts leads to different risk assessments of which protocol to use.

That breaks both ways. You could do maintenance in the middle of the night and break DHCP in unexpected ways (which I've seen happen) and then you have the problem of manually rebooting (or renewing) all those devices the next morning when you notice they're not working.

We really just need to bug our vendors to implement Rogue RA protection for wired and wireless ASAP, wherever we are in our deployment of IPv6.

VLAN per subscriber fixes this. It's not really appropriate everywhere, but it's a nice solution for wireless and ISP scenarios. -- Dan White

David W. Hankins wrote:

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:

...

Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA.

There are some wireless equipment that claim to have a setting that forces all packets through the wireless bridge (where all traffic is between clients and bridge, and never client to client), and so one can filter DHCPv6 and maybe RA, but I am kind of skeptical about how much of this is elective and dependent upon client implementation...

When you're associated to an AP, you're in a "managed" wireless network, where all traffic *must* go through the AP. I've implemented myself a system which firewalled all ARP within the AP and queried the DHCP server asking for the correct MAC for that lease then sent the ARP back (as well as firewalling DHCP servers and the like). It's quite easily doable, and quite reliable. If nodes were to send packets directly when associated to an AP then the 802.11 protocol would fall apart, I've never met an implementation that broke this requirement of the standard.

In both cases there may still be some wireless adapters that receive bogus packets directly from attackers.

You can of course pretend you're the AP and send a packet if you're wanting to be vicious enough.

On wireless networks you can note the mac address of the rouge server and dissociate it from the wireless network, this is rather similar to what we did on switches prior to dhcp protection, it is reactive but it certainly can be automatic. Some controller based wireless systems have ips or nac functionality that does this already. joelja David W. Hankins wrote:

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:

...

Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA.

There are some wireless equipment that claim to have a setting that forces all packets through the wireless bridge (where all traffic is between clients and bridge, and never client to client), and so one can filter DHCPv6 and maybe RA, but I am kind of skeptical about how much of this is elective and dependent upon client implementation...

In both cases there may still be some wireless adapters that receive bogus packets directly from attackers.

And then you bring ND into the question and wonder why you bothered with either RA or DHCP filtering.

DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic authentication.

The problem however has been the key distribution model. Here it all falls down, and leads to poor deployment.

But with DHCPv*, we have a hope that we can secure it if we can solve that last problem (and at least I think we can).

So if you accept that as an outcome, one must ponder the question:

How long will people accept that a secured DHCPv6 session must rely, in order to function to expectations, upon the unsecurable RA and/or questionably secure SEND?

On Sun, 25 Oct 2009 17:33:34 +1100 Karl Auer <kauer@biplane.com.au> wrote:

On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote:

...

the mac address of the rouge server

<pedantic>

It's R-O-G-U-E - rogue.

Rouge is French for red and English for red make-up.

</pedantic>

Also the colour of the faces of angry net admins when they discover a rogue, possibly rouge coloured server.

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

On Sat, Oct 24, 2009 at 11:33 PM, Karl Auer <kauer@biplane.com.au> wrote:

On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote:

...

the mac address of the rouge server

<pedantic>

It's R-O-G-U-E - rogue.

Rouge is French for red and English for red make-up.

Also the name of the Ford assembly plant at which the Monday night social was held. I blame the repeated repetition of the plant name throughout the night for planting it so thoroughly in our collective subconscious. ;)

</pedantic>

Regards, K.

On Sat, Nov 07, 2009, Bernhard Schmidt wrote:

As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this.

How does the client determine that the traffic came from the AP versus another client? Adrian

And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits... Uh, yeah. Owen On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote:

The Wi-Fi MAC protocol has a pair of header bits that mean "from AP" and "to AP." In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set "from AP" but I'm not sure about that. Adrian Chadd wrote:

On Sat, Nov 07, 2009, Bernhard Schmidt wrote:

As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this.

How does the client determine that the traffic came from the AP versus another client?

Adrian

-- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC

Device driver? Nah. Just use a tool (like Scapy) to just arbitrarily, easily custom-craft any packet he|she wants ... Yes, it is that easy. Thanks! /TJ -----Original Message----- From: Richard Bennett [mailto:richard@bennett.com] Sent: Saturday, November 07, 2009 15:37 To: Owen DeLong Cc: Bernhard Schmidt; nanog@nanog.org Subject: Re: {SPAM?} Re: IPv6 Deployment for the LAN It's not all that easy unless the dude has hacked the device driver. Owen DeLong wrote:

And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits...

Uh, yeah.

Owen

On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote:

...

The Wi-Fi MAC protocol has a pair of header bits that mean "from AP" and "to AP." In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set "from AP" but I'm not sure about that. Adrian Chadd wrote:

On Sat, Nov 07, 2009, Bernhard Schmidt wrote:

As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this.

How does the client determine that the traffic came from the AP versus another client?

Adrian

-- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC

-- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC

Port based solutions don't work well on wireless networks and other mediums.

Something like PSPF then? (assuming it works properly on IPv6 multicast ...

) /TJ

Owen DeLong wrote:

...

Not at all. People are not saying RA has to go away. They are saying we need the option of DHCPv6 doing the job where we do not feel that RA is the correct tool.

Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts. DHCPv4 works everywhere and meets every networks needs, from the $50 linksys to the million dollar network. RA already does not. The answer to RA shortcomings is not to turn it into a clone of DHCP, only stateless and chained to the router.

More tools are good. Replacing one tool that works today with a new tool that is arguably inferior in many real world cases, on the other hand, is not so good.

Owen

Sure, leave RA in the IPv6 stack. The market will decide, and we will see if it is still on by default on soho routers and in IOS 15.4T in 2015. Joe

On Oct 22, 2009, at 2:31 PM, TJ wrote:

...

...

...

Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts.

Those two statements are not synonymous ...

They may not be synonymous, but, there is a set of operators for whom both are true.

...

it is still on by default on soho routers and in IOS 15.4T in 2015.

That is a more sensible statement. And were I to be a gambling man I would say it will indeed be on by default ... we'll talk more about it

Sure, leave RA in the IPv6 stack. The market will decide, and we will see if then :).

Also, I would like to add - there is a difference between the default gateway information and other things, such as NTP|DNS|SIP server information.

Maybe.

The default gateway, by definition, is an on-link thing. IMHO, this makes the router a good source for information about the router.

It does in some cases. In other cases, it does not.

I am not saying use cases for "fully spec'ed DHCPv6" don't exist or should be ignored. Making the router capable of sharing the "missing piece" that covers ~95% of use cases is also a Good Thing.

I don't think most people are arguing that it should not be possible to configure a network for RA/SLAAC with the RA providing the gateway information. In fact, I think most of us would like to see RA/SLAAC capable of providing the other needed pieces of the puzzle. That said, there is a group of operators for whom RA is a bad thing, SLAAC is also a bad thing, and, their current usage of DHCPv4 does not map to any existing IPv6 technology, so, they are crying foul and want their needs addressed. I think that is 100% legitimate, regardless of whether Iljitsch thinks we are old enough to play with power tools or not.

Thinking out loud, we could also re-create the idea of an auto-magic DNS by creating a special use case within ULA-space - say FD00::/96, saving the last 32 bits for something like ::53 and using anycast.

That's a fine solution for part of the problem space, but, moving the router assignment function for hosts to a device controlled by the host administrator is a necessary administrative boundary issue for a number of organizations.

*(Could abstract same idea to any stateless and/or light-session-based service ... FD00::123 for Automagic ULA-based anycast NTP, etc. Need 32 bits if we don't want to hex convert the >9999 things, just in case ...)*

NOOO... If you're going to do fd00:: for this, the 123 case really should be fd00::7b, not fd00::123 Owen

В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:

OK... Here's the real requirement:

Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to:

1. Default Router 2. DNS Resolver information 3. Host can provide name to server so server can supply dynamic DNS update 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) 5. NTP servers 6. Boot server 7. Site specific attribute/value pairs (ala DHCPv4 Options)

These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured.

And to add a real-world case for this - two months ago at HAR (hacking at random, a convention in the Netherlands) I was in the network team, handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6 connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at some point we asked the question around - ok, how should we provide DNS and other useful information for the V6 only people? After a while with all the brains around, the decision was to write it on the datenklos through the field, where people can read it and configure it in their browsers. This would've been funny if it wasn't so sad. OTOH, for V4 everything with the DHCP worked fine (as it has always done, even at an event of this size), as is my experience with all the networks I've administered. Saying that DHCP doesn't work for me is extremely weird, as to me this means someone made specific effort to fuck it up. Finally - we have something that works, that's called DHCP. It might not be perfect, it might have some weird issues and implementations, but it's actually making our lives easier, is tested and works. I'd love anything that would be better, but as an option, not as the only choice I have. And it's not just the protocol that I care about. I care about that it's implemented in a HOST, where I can play with the software as much as possible, instead on a ROUTER, which is a vastly different device with rarely-updated OS, and even in the case where they're both the same machine(as in small office environments), they're again handled at different layers (kernel vs userspace). There are reasons that we're using what we're using, and not all of them are "because we're masochistic idiots". -- Regards, Vasil Kolev

Vasil Kolev <vasil@ludost.net>, 2009-10-22 21:03 (+0200):

how should we provide DNS and other useful information for the V6 only people?

What Router Advertisment server did you use? The radvd server supports RFC 5006, an extension to vanilla RA that gives an address to a resolving DNS server (RDNSS). Granted, the client support is still rather poor. I only know of my own radns: http://hack.org/mc/hacks/radns/ and rdnssd: http://rdnssd.linkfanel.net/ The latter is included in some Linux distributions, at least Debian and Ubuntu. -- M.C. Widerkrantz, http://hack.org/mc/ Plain text e-mail, please. OpenPGP welcome.

On Oct 22, 2009, at 4:12 PM, Karl Auer wrote:

On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote:

...

...

If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.

In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see.

It would be a tool, and if someone wants to use a tool, they can. It won't be my thumb they hit :-)

But I can't see how a DHCP server can know enough about the routers to be able to send out useful discrimination information. So it will have to be manually entered, or come from an IPAM, or...

Current practice in the environments I know that are doing this is that groups of hosts are maintained in a database (including MAC addresses) and this database is used to build the DHCP configuration. The host group is assigned a default router address which is actually a VRRP group address. The routers then elect an appropriate VRRP active/standby configuration and the hosts route via the Active router for their VRRP group. If the host administrators find that a host needs to be part of a different VRRP group for whatever reason, there are tools at their disposal to address that issue. DHCP lease times can be short since the addresses are actually static anyway (yes, lots of people use DHCP to assign static addresses in production environments because it allows table-driven central management of host assignment).

Nor can I see how the DHCP server can identify the routers to the host except by their addresses, and these can change or be removed without the DHCP server finding out.

In most environments I know, there are addresses reserved for the VRRP groups that the routers participate in and the router administrators are well aware of the damage they will bring if they change them without extensive planning and notice.

The only way I can see it working is if the host were smart enough to compare the DHCP router discrimination info with the information it has received via RA and delete mismatches, or possibly just revert to using RA information if any mismatches at all are detected. That would be an item the DHCP server could specify as well - what to do in case of a mismatch. It could even be specified on a per-router basis, though the whole thing seems to be getting a bit unwieldy now.

That would be a terrible choice because you have eliminated one of the key reasons that some installations need DHCP to assign router information instead of RA. While what you propose is probably technically cleaner from a pure protocol design perspective, the reality is that pure protocol design is not how the real world thinks or operates. In the real world, one must make the protocol adapt to the business rules and other odd parameters that don't always make logical sense from a protocol design perspective. This is one such example when you have different administrative groups responsible for hosts and routers. <SARCASM>I know it is rare to find an enterprise where the network infrastructure is not run by the same group that does the systems administration.</SARCASM> But in many of these organizations, this means that having the router specify the default gateway to the host is not going to work well for the systems administrators. In today's world, they don't have to worry about this and, the network group, surprisingly, is pretty good at keeping the VRRP groups numbered as they are supposed to be (usually .1, .2, etc. or .254, .253, .252, etc., or whatever the first/last addresses of a segment happen to be).

The DHCP servers will not be on the same subnets as all the routers involved, so they can't sniff the RAs themselves - unless we set up an RA relay... hmm.

They don't need to.

I don't see DHCP-delivered router preferences as being something that will "break the Internet". In the vast majority of cases they will be unnecessary. For those that do need it though, and if it can be done, why not?

Why do router preferences instead of just routers? Sure, the DHCP server doesn't know which router should be doing the routing, but, VRRP can take care of that as it does today. The DHCP server just needs to assign the VRRP group. Owen \

On 22 okt 2009, at 22:52, Mark Smith wrote:

...

...

Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated.

...

Stop trying to break the internet and I'll treat you like an adult.

Great way to shoot down your own credibility. Just because you don't have or don't understand problems other people have doesn't mean they don't have them or they're invalid.

When people want something which is clearly a bad idea (doing default gateways in DHCPv6 the same way as in DHCPv4) and they ignore it when a better solution is suggested (having a DHCP option that allows a DHCPv6 server to tell hosts which of the available routers to use) then the discussion tends to take a turn for the worse.

You'd be far better off proposing alternative solutions that use methods that you believe in, or looking to understand better why your methods aren't appropriate.

I often do that. Unfortunately, in many cases, people not only insist on bad ideas, but they won't even take suggestions on how to achieve what they want in less harmful ways. That annoys me a great deal.

(I don't believe in your agenda to add a prefix length option to DHCPv6 (you probably haven't run an IPX or Appletalk network, and therefore haven't experienced the convenience of fixed length subnets/node addresses), but I don't think it's appropriate to call you a child because of you naivety in this area ...)

But wouldn't hardcoding a prefix length also be a bad idea? We now pretty much always have /64 but there are just enough exceptions to make it dangerous to just assume /64. However, I firmly believe that whether is done with DHCPv6 it will continue to have problems. Even if DHCPv6 itself would operate well and consistently in all cases, then there are still the permuations between hosts that support stateless autoconfig and not DHCP, those that support both, those that are configured to only do DHCP, those that listen for the M/O bits and those that don't... There's simply no way to get consistent behavior out of a set of hosts unless those hosts all run the same version of the same OS. Now for anything else than a configuration protocol that wouldn't be a disaster but for a configuration protocol this is fairly inconvenient.

On Wed, Oct 21, 2009 at 10:08:13PM +0200, Iljitsch van Beijnum wrote:

On 21 okt 2009, at 21:55, Owen DeLong wrote:

...

However, making it available as an option in DHCPv6 allows the end- user/operator to choose the technology that fits their needs best. I do not know why you are so determined to prevent this choice at the operator level.

For the same reason that we don't let the kids play with the powertools: giving them what they want here just makes everything end in tears.

If people want to run DHCPv6, fine, we're all adults. If they want to go to the IETF and fix what's wrong with DHCPv6, so much the better. But taking the information from the place where we can make sure it's correct and putting it in a place where we can only guess so we break the network regularly is A VERY BAD IDEA.

so your not a fan of the smart edge and the stupid network. --bill

On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:

On 22 okt 2009, at 01:55, bmanning@vacation.karoshi.com wrote:

...

so your not a fan of the smart edge and the stupid network.

I'm a fan of getting things right. A server somewhere 5 subnets away doesn't really know what routers are working on my subnet. It can take a guess and then wait for people to complain and then an admin to fix stuff if the guess is wrong, but I wouldn't call that a "smart edge".

Always learn information from the place where it's actually known.

i'm ok w// that mindset. one should learn routing from the router(s), time from the time servers, DNS from the DNS servers, etc... now -normally- I would expect the router to focus on forwarding packets ... not be the time keeper, DNS server, handing out IP addresses, hosting content for the HTTP protocol etc. sounds to me like your reacting to a particular style of implementation (DHCP servers being multi-hops away) and want to move the function(s) closer to the edge, e.g. in the routers. and if we can get RA/ND -fixed- to accomodate all the functions that folks have grown to depend on over the years from a configuration service like DHCP - then we should be able to converge. I am not a fan of the way DHCPv6 has developed/emerged. And yes, I've re-written both client and server to fix the egergious problems found in the current spec... (it now works just fine for doing things like handing out DNS servers for resolvers, picking mapped addresses for my IVI service, etc.) so my DHCP is non-interoperable w/ anyone elses. Thing is, its easier to fix DHCP code than to fix the router code. And the edge is not the LAN, its the device. --bill

On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote:

You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.

Another obvious approach might be to have a service discovery protocol where you send to a "service discovery" multicast group a message asking "wheres the nearest nameserver(s)?" then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a "ServiceDiscovery-Guard" feature for switches....

ah... well - if your a router centric person, then you want to put everything into the tools you know and love. if your a dns centric person, then you put everything in the DNS. I point you to the "DISCOVER' opcode (experimental) in the DNS and the use of DNS over multicast for doing service discovery (e.g. Apples Bonjour)... Most of that is already designed/deployed and in pretty widespread use... over IPv4 or IPv6. And yes, its not RA/ND, or DHCP... its another configuration protocol and its not quite vendor specific. The best thing is, it pushes the smarts closer to the edge (the end device) and this makes me happy.

Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :)

everyone to their own taste. --bill

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would only reach 9999 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? ... Just thinking 'out loud' ... /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Perry Lorier <perry@coders.net> Date: Fri, 23 Oct 2009 00:22:52 To: <bmanning@vacation.karoshi.com> Cc: <nanog@nanog.org> Subject: Re: IPv6 Deployment for the LAN bmanning@vacation.karoshi.com wrote:

On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:

...

On 22 okt 2009, at 01:55, bmanning@vacation.karoshi.com wrote:

...

so your not a fan of the smart edge and the stupid network.

I'm a fan of getting things right. A server somewhere 5 subnets away doesn't really know what routers are working on my subnet. It can take a guess and then wait for people to complain and then an admin to fix stuff if the guess is wrong, but I wouldn't call that a "smart edge".

Always learn information from the place where it's actually known.

i'm ok w// that mindset.

one should learn routing from the router(s), time from the time servers, DNS from the DNS servers, etc...

I quite liked the old http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea. (tl;dr version: Have a set of well known site local anycast address for recursive name servers). It has a number of nice features such as: * since it's not in globally routable space people can't (ab)use your recursive name servers from outside your network. * you don't have to change recursive name servers when going to a different network -- they're the same everywhere. * the addresses can be set as the default addresses by the OS manufacturer, and then don't need to be configured ever again. * If your recursive name server becomes unreachable, broken or otherwise out of contact, it withdraws the address from your IGP, then since you can any cast these addresses, another node takes over. Similar to the shared fate idea of RA's. * You don't tie your recursive nameservers addresses to any point in the network, since they have their own special range, moving them, reshuffling them, or anything doesn't impact anything. They don't need to cohabit a router sending RA's or anything odd like that. However it has a number of obvious drawbacks, primarily amongst them being that it uses deprecated site local addresses. You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers. Another obvious approach might be to have a service discovery protocol where you send to a "service discovery" multicast group a message asking "wheres the nearest nameserver(s)?" then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a "ServiceDiscovery-Guard" feature for switches.... Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :)

On Oct 22, 2009, at 5:00 PM, Perry Lorier wrote:

trejrco@gmail.com wrote:

...

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?

You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using <prefix>:FFFF::1 I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use <prefix>::<protocol assignment>:1 <prefix>::<protocol assignment>:2 and <prefix>::<protocol assignment>:3, where <protocol assignment> could be "0035" for DNS, and "007b" for NTP, and if you're feeling adventurous you could use "0019" for outgoing SMTP relay.

I thought ULA-C was dead... Did someone resurrect this unfortunate bad idea?

...

... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would only reach 9999 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious))

Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ?

Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over.

Why pull this out of ULA? Why not pull it out of 0000/16 or one of the other reserved prefixes? Owen

TJ wrote:

...

...

...

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?

You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using <prefix>:FFFF::1

FWIW - I think simple anycast fits that bill.

I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. There are some protocols that anycasting doesn't work well for, they may require multiple instances.

...

...

I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use <prefix>::<protocol assignment>:1 <prefix>::<protocol assignment>:2 and <prefix>::<protocol assignment>:3, where <protocol assignment> could be "0035" for DNS, and "007b" for NTP, and if you're feeling adventurous you could use "0019" for outgoing SMTP relay.

IMHO non-hex-converted port numbers works cleanly ... ?

Up to 9999, if you want to announce a service port 30,000 you're in trouble. Also quite a few protocols don't have "well known" ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports >9999 and protocols that don't have "well known" ports could get an unused one assigned to them.

...

...

...

... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would only reach 9999 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious))

Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per-function mentioned above, then perhaps useful.

In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above).

On Oct 23, 2009, at 5:45 AM, TJ wrote:

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?

...

...

...

...

...

You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using <prefix>:FFFF::1

FWIW - I think simple anycast fits that bill.

I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device.

Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ...

Please remember that IPv6 DNS is OFTEN not stateless as the replies are commonly too large for UDP.

...

There are some protocols that anycasting doesn't work well for, they may require multiple instances.

Fair enough; could also standardize something like FD00::<port number>, FD00::1:<port number>, and FD00::2:<port number> ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... )

That's what I meant by prefix::<inst:ance>:<serv:ice> <instance> would be a 32-bit instance value and <service> would be a 32 bit service value (probably port number in the low order bits initially).

I personally would suggest getting a well known ULA-C allocation

...

...

...

assigned to IANA, then use <prefix>::<protocol assignment>:1 <prefix>::<protocol assignment>:2 and <prefix>::<protocol assignment>:3, where <protocol assignment> could be "0035" for DNS, and "007b" for NTP, and if you're feeling adventurous you could use "0019" for outgoing SMTP relay.

IMHO non-hex-converted port numbers works cleanly ... ?

Up to 9999, if you want to announce a service port 30,000 you're in trouble.

...

Also quite a few protocols don't have "well known" ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports >9999 and protocols that don't have "well known" ports could get an unused one assigned to them.

OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port 9999 based on automatically using port numbers (or using automatically registered port numbers, see below).

Why use the non-hex converted? Is it really hard to realize that 0x35 = 53?

Maybe FD00::FFFF:xxxx/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses.

...

... Heck, start a registry (@IANA) and add in FD00::101, etc. ...

...

...

...

Maybe reserve FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would only reach 9999 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious))

Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per- function mentioned above, then perhaps useful.

In my humble opinion I'd have them registered, linking them to port numbers

...

means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above).

OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...)

And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc.

Agreed, but, since this mostly doesn't get typed by humans, I think that using 0x35 is much better in this case than using 0x53 -> 53 stuff. Owen

...

I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device.

Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ...

I'm thinking for places like home users and the like which don't really run an IGP, can't correctly identify a router, and when you say "anycast" think that you might be talking about a new form of fishing.

...

There are some protocols that anycasting doesn't work well for, they may require multiple instances.

Fair enough; could also standardize something like FD00::<port number>, FD00::1:<port number>, and FD00::2:<port number> ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... )

3 seems to me to be plenty for most cases. For some things like NTP you might want to have 4 or more.

OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port 9999 based on automatically using port numbers (or using automatically registered port numbers, see below).

Maybe FD00::FFFF:xxxx/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses.

Seems sane to me.

In my humble opinion I'd have them registered, linking them to port numbers

...

means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above).

OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...)

And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc.

Yup, and it makes a sane default, if you want to override with DHCP, or some funky RA option, or manual configuration or whatever, then this gets out of your way and you don't have to care. It doesn't involve any code changes on hosts *or* routers to work today.

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?

...

...

...

Needs an acronym ... off the top of my head, something like ASPEN -

Anycast Service Provisioning for Enterprise Networks ... ? (Although it could be appropriate for an ISP-HomeUser as well ... hmmm, SPATULA - Service Provisioning - Anycast, Transparent, Unique Local, Anycast ... )

<<major snipping>>

Exactly, seems easy, straight forward, robust, reliable and allows for

...

...

things like fate sharing and fail over.

I have no major thoughts either way as to exactly where the range comes from other than it should be an easy to spot, and easy to type range which suggests plenty of 0's :)

I don't have any "major thoughts" on this either, still thinking out lout / rambling. :) /TJ

I figured 0000 was a good candidate since it's already partially in use

...

for reserved special addresses.

But in a totally non-routable fashion, as it stands today. ULA's have the immediate benefit of being routable, but not globally so - and (hopefully) already being in filter lists to prevent accidental implementation. /TJ

Iljitsch van Beijnum wrote:

This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4.

No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! A

Amen to that Randy. MMC Randy Bush wrote:

...

...

This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4.

No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 !

no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is soooo wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol.

v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills.

randy

On Thu, 29 Oct 2009 08:40:46 +0900 Randy Bush <randy@psg.com> wrote:

...

...

This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 !

no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is soooo wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol.

v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills.

As does excessive pessimism.

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 <smb@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/

On Oct 18, 2009, at 2:38 PM, Ray Soucy wrote:

On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin <smb@cs.columbia.edu> wrote:

...

My question is this: what are your goals? What are you trying to achieve?

As I read this whole thread, I had similar questions coming to mind.

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.

I do not understand the big concern here, but that is probably because my own perspective and approach is somewhat different than yours. In my humble opinion, those of us that are network operators need to provide robust IPv6 connectivity and services to our customers today, and customers with IPv6-enabled devices should automatically have IPv6 connectivity (i.e. automatically get an address and default route) with minimal hassle and configuration effort on their side. If they decide they don't want IPv6, it is up to them to disable it, because they are the exception, not the rule. Besides, systems administrators are probably the wrong ones to ask, because they will most often opt for "don't change anything that might break something or make me do more work". I just don't see how SLAAC is holding back deployment. In my experience, SLAAC is your friend, given that DHCPv6 is not yet available for most of the client world (i.e. Windows XP, Mac OSX). I've seen only one case out of thousands of customers where enabling IPv6 on the client broke access to a single remote web site, but that was because of a flaw in the DNS implementation for that remote site. Wait, there was one other case where the problem turned out to be a bad NIC. I think you are overly concerned about breaking someone by enabling SLAAC on all your nets. Rather, focus on making sure that you have robust IPv6 connectivity and infrastructure and peering/ transit. If you do find situations where something breaks, then put your energies into resolving those situations, which benefits the whole community. Our philosophy has been "aggressive IPv6-enablement is the right thing to do, and don't be afraid to break some glass".

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.

Those cases are increasingly rare, and can be fixed. Don't let such concerns stop you from IPv6-enabling your nets. As a network operator, you are doing the right thing by enabling IPv6 on all your nets, and it is not your fault if sys admins aren't keeping their systems patched.

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).

When I started rolling out IPv6 to my nets many years ago, I was of the same mindset. I wanted the same mechanisms for managing addresses and DNS as I had in place for IPv4, and do dynamic DNS updates out of DHCP. But, I quickly changed my approach after seeing the huge lack of client side support for DHCPv6, and serious interoperability issues where it did exist. What we did find is a fairly simple means to use SLAAC and still keep DNS updated automatically for IPv6 addresses by polling the routers and doing the mapping to clone the IPv4 DNS entries for IPv6. That works very well for us.

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.

I would be more concerned with deviating from the mainstream of /64, and the potential problems you will encounter when doing so, than I would be for the few machines that might break when encountering SLAAC.

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).

Using SLAAC for servers has not been a problem for us at all. Many server admins also want to use manual IPv6 addressing, and that is perfectly fine with us if that is their choice. I just don't see a problem with this.

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?

Until every network device has a built-in DHCPv6 client, I need SLAAC. Even then, I have a number of special case networks where DHCP is overkill if I have SLAAC available to me. But on the other hand, for some network situations (like if you are using IVI as a transition mechanism for your net) then DHCPv6 is mandatory. So I argue that we need both.

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 agree that this is a huge shortcoming on the part of Apple. Everyone needs to file appropriate bug reports with Apple and complain about lack of DHCPv6 support. Good luck on your IPv6 deployment efforts. Regards, --Ron

On Thu, Oct 22, 2009 at 11:12:14AM +1100, Karl Auer wrote:

...

To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band through some means. This does neatly work around the problem; the hosts may now speak to one another.

I don't understand this. Could you elaborate? It seems to me that the "simplest network imaginable" should still operate on link local addresses.

To use a link local address, you also have to supply the application with the interface name for it to be used upon. The application has to pass this as an extra argument when opening a socket; it isn't part of the regular gethostbyname/socket/connect. Provided you have applications that have a separate dialog field for the interface name so LL's can be used, you're probably going to be entering in the IPv6 LL address in all its glory. First, you are not going to have LL addresses in /etc/resolv.conf because you can't list interface names there (I think it is the same for other OS's analogues of their nameservers list), and second people are not going to be very well motivated to put LL addresses in DNS because those addresses are not globally applicable; they would have to use DNS views. So it is not really very realistic to expect LL to actually be used except to bootstrap. Maybe it's possible for some proprietary printer or fileshare network stuff to continue working on LL's (or, ironically, routing protocols or DHCPv6 itself), but anywhere else ("mail.example.com", "contacts.example.com"), anywhere real, and the network goes dark. Unless of course it can fall back on native IPv4, or has entered a bogus covering /64. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins

On Fri, Oct 23, 2009 at 10:25:10AM +1100, Karl Auer wrote:

I think it was really this that I was wanting more info on. "Entered" where?

On the address configured on the interface typically, or whatever other system specifical local means are used to enter a route for the prefix for the interface. Typically on Linux; ip=/sbin/ip ${ip} -f inet6 addr add ${new_ip6_address}/${new_ip6_prefixlen} \ dev ${interface} scope global -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins

On 21 okt 2009, at 23:34, David W. Hankins wrote:

There is a problem with the "Both RA and DHCPv6 Model" currently proposed by IETF iconoclasts. Should RA fail, for any reason from router, system, software, network path, security, or user error, then the simplest networks imaginable (where hosts and mail/Intranet/ work servers are all co-located on the same broadcast domain) will not be able to talk to one another,

Or the rest of the world. Note however that it is very hard to get false negatives for RAs and even harder to get false positives. The only way I've had RAs fail in the real world was with multilayer switches that wouldn't let IPv6 multicasts through because they couldn't do IGMP snooping for those. This affected RAs but also all other neighbor discovery, and would have affected DHCPv6, too. So in this situation IPv6 is completely dead in the water. The good thing is that you don't get any false positives, where a host thinks there's a router somewhere but there's not actually a router there. This is because when a router stops being a router it will also stop sending RAs. All of this works extremely well, I can't think of any instance where there is any trouble with RAs, except of course the problem of rogue routers advertising themselves. However, this is not really any different from the situation in IPv4 where rogue DHCP servers advertise stuff they shouldn't advertise.

To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band through some means.

Why not simply fix the DHCPv6 protocol so it has a prefix length attribute? DHCP'ers can complain about stateless autoconfig and RAs, but the simple truth is that DHCPv6 has problems that are unrelated to anything outside DHCPv6 that haven't been fixed in the half a decade that I've been paying attention to it.

But it may complicate your designs if you are assigning /80's.

RFC 3513 says that all interface identifiers for addresses outside ::/ 3 must be 64 bits in size. That doesn't work with a /80. So I'm not sure if using DHCPv6 with /80s will work on all systems.

According to the release notes of ISC DHCP 4.1.0, ISC 'dhclient -6' compiles and runs on Mac OSX. I don't actually own a Mac, so I have never used it myself, and our release notes even go into detail about the limitations of the current 'dhclient-script' for the Darwin platform (apparently their configuration system is somewhat opaque).

MacOS detects when interface go online and offline and does all kinds of stuff when that happens. For instance, you can't globally enable/ disable stateless autoconfig on MacOS, either. Manually running a script when the interface status changes is a rather blunt way to interact with the system.

...

Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X?

No...but I have heard plans of the exact opposite.

[...]

When people at the microphone asked why Apple did not include a DHCPv6 client implementation, even a stateless one, I believe Bernard Aboba addressed the concern at the microphone saying, and I am paraphrasing from memory here, "We were told by the IETF that RA was all we would ever need, implementing DHCPv6 is optional, so RA is all we are doing."

I don't remember that. What I do remember is that Stuart Cheshire of Apple explained how he was unhappy that it was necessary to run a rather involved protocol (DHCPv6) for the relatively simple task of obtaining DNS resolver addresses.

To summarize, RA+DHCPv6 implementers are posed with problems:

...which apparently some DHCPv6 people want to solve by ALWAYS running their chatty protocol that wastes a lot of bandwidth on wireless LANs until people give in and just run a DHCPv6 server just to get rid of the constant DHCP retransmissions that can't be stopped any other way because actually looking at the O/M bits is of course way too simple. I hate this crap so much.