Subject: Re: [69ATTENDEES] DHCP

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 12:17:22 -0500

[people were complaining about delays in getting an IPv4 address over  
DHCP, CCing the v6ops list to make a point]

On 24-jul-2007, at 10:19, Jun-ichiro itojun Hagino wrote:

> 	good reason to use IPv6 entirely, as long as you have IPv6 DNS  
> server:-P

More specifically, stateless autoconfig seems to work a lot better  
than DHCP in this case: one router advertisement can provide a large  
number of clients with address and configuration information, while  
DHCP requires messages back and forth for each individual client. A  
good reason to make sure that it's possible to run IPv6 with all that  
that entails (= DNS resolver addresses) without the need to run  
DHCPv6 if running DHCPv6 isn't specifically desired.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 24 Jul 2007 12:45:10 -0500

Fully agree.

I was absolutely unable to get DHCP working during more than two hours
yesterday afternoon, which is unacceptable in my opinion.

However I was able to use IPv6, manually configuring my own IPv6 DNS
resolver from my home network.

It will be really nice to make sure that we can progress with more
parameters available in the RA.

And by the way, unfortunately the DHCP issues are very very very very
frequent in many networks, not sure if its a protocol/design issue or just
not so good DHCP implementations, but it is the reality.

Regards,
Jordi

> De: Iljitsch van Beijnum <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 24 Jul 2007 12:17:22 -0500
> Para: Jun-ichiro itojun Hagino <[email-masked]>
> CC: IPv6 Operations <[email-masked]>, <[email-masked]>
> Asunto: Re: [69ATTENDEES] DHCP
> 
> _______________________________________________
> 69ATTENDEES mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/69attendees

---

From: james woodyatt <[email-masked]>
Date: Tue, 24 Jul 2007 13:08:21 -0500

On Jul 24, 2007, at 12:17, Iljitsch van Beijnum wrote:
> [...]  A good reason to make sure that it's possible to run IPv6  
> with all that that entails (= DNS resolver addresses) without the  
> need to run DHCPv6 if running DHCPv6 isn't specifically desired.

dns-sd -Q _domain._udp.local SRV --> /etc/resolv.conf

Quite a thrilling proposal from a security perspective, but it's  
worth contrasting with the idea of reserving a global IPv6 anycast  
address for DNS resolving proxy servers.  At least with the latter, a  
public network operator has an easier time keeping rogue DNS  
resolvers from poisoning the network.  On the other hand, the former  
*is* clearly BETTER THAN NOTHING, which is what we have now.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 03:08:31 +0900 (JST)

now i see rogue RAs which advertise fec0:0:0:4::/64 and
	202:8281:1768:4::/64.  my guess is that this is from the same guy.

	we need L2 switch vendors to implement ways to prevent rogue RA/DHCPv6
	sources, just like ways to avoiding rogue DHCPv4 servers/relay agents.

itojun

---

From: Tim Chown <[email-masked]>
Date: Tue, 24 Jul 2007 19:22:36 +0100

> resolver from my home network.

Well I think a number of people have put a lot of work in to avoid
open IPv4 recursive DNS servers...
 
> not so good DHCP implementations, but it is the reality.

As Itojun has spotted, there are rogue IPv6 RAs on the network, so IPv6
is not necessarily any better for you in this type of network.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 24 Jul 2007 19:30:38 +0100

> 	sources, just like ways to avoiding rogue DHCPv4 servers/relay agents.

Any comments on

http://www3.ietf.org/proceedings/07jul/slides/dhc-5.pdf

to the v6ops list would be welcome.   A couple of us will be converting
this material, which was assembled from talking to various admin type
people from enterprise networks, into an informational draft in the next 
couple of weeks.   The draft will include feedback received from dhc and 
v6ops WG meetings yesterday, and hopefully generate some discussion
towards 'bcp' type advice.

-- 
Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 13:58:55 -0500

> to the v6ops list would be welcome.

Ignoring all the protocol details for a moment, it seems to me that  
the problem here is sourcing some kind of authentication between the  
network and the host. There are several mechanisms that allow the  
network to ask the host/user for credentials:

1. 802.1x
2. 802.11 WPA(2)
3. PPP PAP/CHAP

It would make sense to make the authentication work the other way  
around as well, so you know you're actually talking to the network  
you think you're talking to (goodbye man in the middle and rogue  
access points) and then you can use that authentication data to  
futher authenticate later stages in the configuration process, such  
as RAs or DHCP.

The scope of the work required is rather extensive, though, and many  
of the protocols used today aren't even IETF protocols. But getting  
this right would clearly be beneficial, if only to get rid of those  
annoying hacks that wifi hotspots use for authentication and payment.

---

From: Roland Bless <[email-masked]>
Date: Tue, 24 Jul 2007 21:08:26 +0200

Hi Jordi,

> yesterday afternoon, which is unacceptable in my opinion.

Luckily there weren't such heavy DHCP problems in the past
few IETF meetings. However, we had them some time ago
and are obviously common.

> parameters available in the RA.

Yes, but host implementations must also be enable to make use
of such features...

> not so good DHCP implementations, but it is the reality.

I can second that. I guess it is indeed a problem of broadcasting,
per client request processing and packet loss. Stateless autoconfig
seems to be much more robust and efficient in these cases.

Regards,
 Roland

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 24 Jul 2007 22:19:16 +0300

> is not necessarily any better for you in this type of network.

There are really two different sorts of "rogue" RAs. Different in 
their "motivation" and different in the way you can deal with them.

One type is the evil RA, that is purposedly meant to do something nasty. That, 
I think, can only really be dealt with proper layer-2 access security, or 
with SeND. Using DHCP only raises the implementation complexity for the evil 
guys, as you pointed out yesterdat.

The other type, is the lamely configured node. Most often that will be a host 
that automatically servers as 6to4 gateway when it has a public IPv4 address. 
I think Windows XP SP2 or Vista do that with Internet connection sharing 
enabled, for instance. I doubt we need protocol extensions for this 
particular case. It might be common at interop.net (incl. IETF) meetings, and 
rampant in some universities campuses, but that's about it.

For that case, beside the various kludges we've already discussed during/after 
Prague:
- 2002:... advertisements that do not include a non-6to4 non-site-local prefix 
when there is at least one such prefix on the same link (defensive mechanism) 
could be ignored altogether,
- "promiscuous" automated 6to4 routers should likely not advertise on any 
interface that is assigned a public IPv4 address since other nodes on the 
link can most likely get 6to4 by themselves,
...

-- 
Rémi Denis-Courmont

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 24 Jul 2007 14:30:02 -0500

Le 07-07-24 à 13:58, Iljitsch van Beijnum a écrit :

> the problem here is sourcing some kind of authentication between  
> the network and the host. There are several mechanisms that allow  
> the network to ask the host/user for credentials:
>
> 1. 802.1x
> 2. 802.11 WPA(2)
> 3. PPP PAP/CHAP
>
> you think you're talking to

SEND[RFC3971]?

Marc.

> (goodbye man in the middle and rogue access points) and then you  
> can use that authentication data to futher authenticate later  
> stages in the configuration process, such as RAs or DHCP.
>
> The scope of the work required is rather extensive, though, and  
> many of the protocols used today aren't even IETF protocols. But  
> getting this right would clearly be beneficial, if only to get rid  
> of those annoying hacks that wifi hotspots use for authentication  
> and payment.

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 24 Jul 2007 13:53:09 -0500

However, I can avoid using the rogue IPv6 RAs, but I've no way to configure
IPv4 if DHCP is not working, so I prefer IPv6 problem vs. DHCP failure.

Regards,
Jordi

> De: Tim Chown <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 24 Jul 2007 19:22:36 +0100
> Para: IPv6 Operations <[email-masked]>

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 24 Jul 2007 22:43:45 +0200

> Yes, but host implementations must also be enable to make use

It would be even better if there was even content I could access with  
or without those features...

- kurtis -

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 07:11:14 +0900 (JST)

i'll try to summarize what i know of about handling rogue RAs.

	- L2 switch solution: filter rogue RAs in the switches, just like
	  filter rogue DHCPv4.  you can detect potential RA sources by
	  MLD joins to ff02::2 (all-routers link local multicast addr).
	  CONS: you cannot protect victims within the same wireless
	  base station, for instance.

	- end node host firewall solution: at every node, look at the content
	  of RAs and reject them if they advertise prefixes like
	  fec0:0:0:xxxx::/64.
	  CONS: not widely deployable, can filter false positives

	- KAME rafixd: shoot down rogue RAs by announcing against those rogue
	  RAs with 0 prefix/router lifetime
	  PROS: easy to deploy, maybe we should ship it with *BSD
	  CONS: need to take down the source of rogue RA anyways

	using DHCPv6 is NOT a soultion, as you can see rogue DHCPv6 server/
	relay agent just like rogue RAs.
	  
itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 18:01:22 -0500

> 	i'll try to summarize what i know of about handling rogue RAs.

[...]

Another option would be for hosts to do something similar to neighbor  
unreachability detection for their default gateway.

One thing that annoys me to no end is that if router X sends out  
prefix A::/64 and router Y sends out B::/64, then node 1 will happily  
configure addresses A::1 and B::1, and then send out packets with  
source address A::1 over router Y. This is really a bad thing for  
efforts like shim6.

So trying to use the router that gave you the prefix for the source  
address you're using is a good start. The next one would be to avoid  
routers that announce obviously tunneled reachability such as 6to4 or  
Teredo.

Actually detecting whether a default gateway works and then switching  
to another would be more difficult, but that should help against  
rogue RAs and also (if/when a gateway address through DHCPv6 becomes  
possible) rogue or misconfigured DHCPv6 in most typical cases,  
although of course a careful attacker could deliver the packets after  
inspecting/modifying them, but we have IPsec/SEND against that, if  
you care enough to defeat an attacker that cares enough to do that  
you'll go through the effort of making those work.

And it will detect and repair a class of failures that is currently  
fatal.

Best thing, all of this can be done in implementations without the  
need to create or change protocols.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 08:07:04 +0900 (JST)

> source address A::1 over router Y. This is really a bad thing for  

	first of all, the above configuration violates RFC.  all routers has
	to be configured with consistent RA parameters iirc.  i know it is not
	practiced in reality.

	however, ICMPv6 redirect should take care of it if there's any issue
	with that.  anything wrong with redirects, other than getting
	(potentially tons of) /128 routes?

	also, "RAs with more specific route" (RFC4191) may help you assuming
	router Y is not a rogue router.

> routers that announce obviously tunneled reachability such as 6to4 or  

	we've been there with KAME, and we conclued it is a bad idea to
	tie prefixes/source address selection to routers/RAs.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 19:02:27 -0500

> 	to be configured with consistent RA parameters iirc.  i know it is  

Then we fix this in a future version of the document. Obviously this  
is an unworkable requirement in practice, and I don't see why it  
should be needed anyway.

> 	(potentially tons of) /128 routes?

Redirect is based on destination address, I'm talking about the  
source address. The number of source prefixes is so low and known by  
the host anyway that having router feedback for this is not  
necessary, the host can do this itself without help if implementing  
this is desired.

> 	router Y is not a rogue router.

That's again for the destination address.

> 	tie prefixes/source address selection to routers/RAs.

What were the problems or disadvantages of doing that?

Iljitsch

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 09:14:24 +0900 (JST)

> is an unworkable requirement in practice, and I don't see why it  

	it was about prefix lifetime if i remember correctly (for jinmei it
	is night time in Japan, but he will be here any moment).
	if two routers advertise different prefix lifetime, hosts will go
	crazy.

> necessary, the host can do this itself without help if implementing  

	ok, then you are in the maze of policy routing.  see comments from me
	to [email-masked].

> That's again for the destination address.

	yup.

> What were the problems or disadvantages of doing that?

	the routers which issue RA, and the routers which terminate external
	links are not usually the same (unless you are in a home network where
	there's only single link).  so you do not have clear knowledge about
	how to issue RA parameters.  normally you only have 1 router on your
	link (which is not directly connected to the egress router), so you
	cannot have separate routers for separate prefixes.

  |	  |
egress1	egress2
  |	  |
==+=======+==
  |
router
  |
==+==
  |
router
  |
==+==
  |
your host

itojun

---

From: james woodyatt <[email-masked]>
Date: Tue, 24 Jul 2007 19:20:09 -0500

On Jul 24, 2007, at 15:43, Kurt Erik Lindqvist wrote:
>> [at some point, somebody wrote:]
>>>
> It would be even better if there was even content I could access  
> with or without those features...

"If you don't like the news, go out and make some of your own."  -- 
Wes "scoop" Nisker

One of the concerns behind my original initiative to leave the  
*stateful* part of the IPv6 packet filter turned off by default in  
the AirPort Extreme 802.11n base station was my [apparently mistaken]  
judgment that the measurable benefits for network security it  
provided were heavily outweighed by the opportunity cost it posed by  
hindering the deployment of ad-hoc peer-to-peer applications where  
the vast majority of peers are expected to be at the end of the last  
mile in a residential deployment.

P2P applications already very difficult for average Internet users to  
participate effectively in such networks due to the stateful  
filtering in IPv4/NAT gateways, and services like UPnP IGD and NAT- 
PMP don't repair all the damage.  If these packet filters are allowed  
to become ubiquitous in IPv6, then my fear is that the most likely  
applications that would otherwise be able to deliver that content  
you'd like to access, with or without any whizzy new router  
advertisement parameters, will never be developed for IPv6 where they  
might be simple enough for average users to operate.  All the user  
complexity created by IPv4/NAT stateful filters will have been  
duplicated in the IPv6 stateful filters.

If we are not careful, IPv6 may be saddled with all the b0rkenneff  
that IPv4/NAT plagues us with today, without any measurable benefit  
beyond merely addressing the burdensomely high and rapidly increasing  
cost of public IP addresses.  We are setting up a vicious circle.

+ Nobody will want to use IPv6 because there isn't any content worth  
accessing, while...

+ Nobody will develop content worth accessing because IPv6 is more  
difficult to use than IPv4, and in fact, is also broken fundamentally  
in ways that IPv4/NAT isn't, while...

+ Nobody will have any incentive to make IPv6 any easier to use  
because users aren't interested in any of the content available  
exclusively via IPv6, while... [lather, rinse, repeat]

If this happens, mark my words: IPv6 will wither and die-- and it  
will not be an honorable death, as IPv4/NAT will be wielding the  
sword that cuts it down.  Those among us who really, really despise  
NAT might do well to bear in mind all the ways we could be  
undermining our own objectives by failing to consider how we might be  
preventing IPv6 from being usable by new applications in ways that  
IPv4/NAT will never be able to match.

Still working on polishing my philosophy essay.  Sigh.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 09:39:19 +0900 (JST)

> cost of public IP addresses.  We are setting up a vicious circle.

	yup, you have some points.

	i'm very hopeful in the following way of thinking:

	- normal users do not really care what is underlying technology.
	  in fact, famous Japanese magazine, Hanako, had "the Internet for
	  newbies" feature without single mention of IPv4 address.

	- operators and implementers can reduce administration costs by using
	  IPv6, because of vast amount of available address space, and because
	  of this, fewer administration costs.  of course, to achieve this,
	  you need some knowledge to avoid unneeded admin costs people are
	  paying with IPv4 and NAT.
	  for instance, if you try to deploy all-IP cellphone network, you
	  would need a gigantic NAT box that supports SIP NAT with
	  failover/redundancy if you pick IPv4.  if you pick IPv6, you do not
	  need that.
	  i have been trying to promote this idea here, maybe i should keep my
	  mouth shut and charge money for my recipe ;-)

	- normal user do care about overall cost of operation and would like
	  to have fewer support calls/cableguys come to home, so they would
	  pick ipv6-based services with less costs, IF IT IS DESGINED WELL.

	and more importantly,

	- because the population with IPv6 connectivity will gradually
	  increase, you can start small with your IPv6 service.  you do not
	  have to have giant load balancer like your IPv4 service today.
	  you just need to prepare for growth in the near future.
	  for instance, with IIJ IPv6 connectivity service (started 1999)
	  all the support calls are diverted to small number of IIJ people
	  if it contains the word "IPv6".  the important thing is for call
	  center people to be able to handle IPv6 questions, and divert it
	  to appropriate people.

	am i being too optimistic?  i guess not.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 25 Jul 2007 14:59:04 +0900

At Wed, 25 Jul 2007 08:07:04 +0900 (JST),
[email-masked] (Jun-ichiro itojun Hagino) wrote:

> 	to be configured with consistent RA parameters iirc.

(A very minor comment that is not related to the main point of this
thread)
This is not really correct: the specification allows router X to send
out A::/64 (and only this one) and router Y to send out B::/64 (and
only this one).  See Section 6.2.7 of RFC2461:

   Note that it is not an error for different routers to advertise
   different sets of prefixes.  [...]

(This isn't going to be changed in 2461bis for that matter).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Roger Jorgensen <[email-masked]>
Date: Wed, 25 Jul 2007 09:17:57 +0200 (CEST)

On Wed, 25 Jul 2007, Jun-ichiro itojun Hagino wrote:
<snip>
> 	to be configured with consistent RA parameters iirc.  i know it is not

it happen quite easy on a network, just configure two devices that 
announce RA :)

the host will pick up both and use one of them, havent seen a pattern on 
which one it choice tho.

-- 

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
[email-masked]           | - IPv6 is The Key!
-------------------------------------------------------

---

From: David Malone <[email-masked]>
Date: Thu, 26 Jul 2007 20:00:18 +0100

> 	  base station, for instance.

In 802.11 infrastructure-mode networks, communication between
stations is not direct, but relayed through the access point. The
access point could filter rogue RAs in the same way as a switch
would.  This still leaves the problem of rogue access points or
access point impersonation, but at least makes it part of a more
general well-know problem with 802.11.

(I think part of the 802.11e spec allows direct communication between
associated stations, but I'm not sure how that relates to multicasts
and broadcasts.)

	David.

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Jul 2007 15:08:44 -0500

> associated stations, but I'm not sure how that relates to multicasts

It was subsumed into the forthcoming 802.11n specification, and it  
only works for unicast transmissions.  This implies that RA  
announcements could be filtered, and router discovery multicasts  
could conceivably be screened and not forwarded past the AP at the  
802.11 layer.  However, DLS could still be used to send RA unicasts  
to attack hosts willing to accept them.