Subject: RE: RS Lost failure scenario (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 2 Sep 2010 11:31:01 -0700

Hi Suresh,

Suresh Krishnan wrote:
> 
> Hi Ralph,
>    <Snipped a whole lot of old quoting>
> 
> On 10-08-26 08:18 PM, Ralph Droms wrote:
> > Suresh...
> >
> > But the multicast RAs don't advertise prefixes, right, so the
> > subscriber nodes won't be able to complete SLAAC?
> 
> Correct.
> 
> > I think the point is to use standard node stacks: Windows 7, OS X,
> > Linux.  Do any of them send periodic RSs?
> 
> No. All of them send RSs (3) on interface initialization. If no routers
> are found, there is no periodic retransmission mechanism like for DHCPv6
> Solicits. This is true of SLAAC in general (with or without RS marking).
> 
> > But this option isn't all that is needed for the deployment
> > architecture,
> 
> Correct. But the rest is standard RFC4861/RFC4862 behavior.
> 
> > and it appears that there is a significant problem with that
> > deployment architecture.
> 
> I would not say it is a problem with the deployment architecture. As I
> said in mails to Thomas and Woj, the issue occurs in other deployment
> architectures that need to use different prefixes over the same shared
> L2 domain (e.g. WLAN AP with 2 SSIDs mapped into 2 VLANs on the fixed
> side connected to the edge router).

In your example above, two SSIDs mapped into 2 VLANs on the fixed side connected to the edge router would consistently appear as two links to both WLAN STAs, BSs, and edge router. 

The edge router can advertize on each of these links a different prefix via a multicast RA sent on the link. All of the WLAN STAs attached to that link (or SSID if you will) will receive the appropriate prefix and be able to complete SLAAC even though they have not sent an RS out.

This seems different from the BBF architecture where the edge router can't sent a multicast RA that contains the PIO prior to having received an RS...

--julien

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Tue, 7 Sep 2010 19:08:23 +0530

Suresh,

One of the main challenge in implementing the model proposed by the draft 
is that edge router has no reliable indication if a host (once it has sent an RS)  
is present on the network or not.

Please see detailed comments below..

--
Shree

1.  Prefix Lifetime Binding/Expiry..

	Unlike DHCP there is no mechanism with SLAAC for a host (client) to renew its address/prefix binding.
	Relying on host to send a router solicitation (as a keep alive) toward edge router is not a viable option.
	
	RFC 4861 (section 6.3.7 )
	
	Router solicitation "may" be sent after following events
       
		- The interface is initialized at system startup time.
		- The interface is reinitialized after a temporary interface
		   failure or after being temporarily disabled by system
		   management.
		- The system changes from being a router to being a host, by
		   having its IP forwarding capability turned off by system
		   management.
		- The host attaches to a link for the first time.
		- The host re-attaches to a link after being detached for some time.	
       
	In such an situation what is the mechanism for edge router to time out a binding from its database ? 

2. Sending Unsolicited router advertisements

	Since the PIO's are specific to each end-device (RG or host) the edge router needs to send unsolicited router advertisements to each end-device.
	In this case what is the expected behavior of edge router , does it still confirm to section 6.2.4 of RFC 4861 
	and the bounds of delays between router advertisements ?  

	With max router lifetime of 9000 sec (RFC 4861) and MinRtradvInterval (3sec - RFC4861) 

	Only 3000 unsolicited RA's can be sent before router lifetime expires (this may restrict the scaling).

3. Denial of Service attack 

	-  Since bindings can't be timed out is the edge router susceptible to a denial of service attack based 
	   on changing source hardware address of router solicitation message. 

 	This can be a distributed DoS, or 
	a delayed DoS e.g. where a malicious node sends a router solicit (with 8 different MAC addresses) waits for 30 mins 
	(so access node times the 8 MAC's out of it's FDB) then sends another 8 router solicits and so on so forth
	Till the edge router runs out of resources..

4.  What happens when a L2 MAC address is not in the FDB.

	The RA's are unicast presumable to avoid them being flooded to other nodes for security reason (a node is only aware of it's prefixes). 
	 What happens when a node who is allocated a prefix is powered off and it's link layer (MAC)  address is no longer in FDB of L2 network (access node).
	Is the packet flooded to all hosts/RG's ? doesn't that defeat the purpose ?

5.  Creating an alternative to DHCPv6 ?

	One SLAAC is defined to do functionality similar to DHCP (including per host prefixes/options) 
	how long before options are added so SLAAC becomes an alternative to DHCPv6 ?

--
Shree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Saturday, August 28, 2010 12:27 AM
To: Thomas Narten
Cc: IPv6 WG Mailing List
Subject: Re: New version available (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

Hi Thomas,

---

From: Doug Barton <[email-masked]>
Date: Tue, 07 Sep 2010 23:02:51 -0700

On 09/07/2010 06:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
> One SLAAC is defined to do functionality similar to DHCP (including
> per host prefixes/options) how long before options are added so SLAAC
> becomes an alternative to DHCPv6 ?

This is the basis of my opposition to adopting the draft (expressed 
neatly here, as well as by other authors in this thread).

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 Sep 2010 19:20:47 +0930

On Thu, 26 Aug 2010 09:20:45 -0400
Thomas Narten <[email-masked]> wrote:

> Suresh,
> 
> Suresh Krishnan <[email-masked]> writes:
> 
> > The nodes attached to different subscriber lines cannot directly send 
> > packets to each other. They need to talk through the edge router.
> 
> How is this enforced? If I happen to know the mac address of my
> neighbor's router (or host), can't I just send stuff directly?
> 
> If I happen to send bogus NAs to my neighbor, does the architecture
> prevent this?
> 
> > All traffic needs to go through the edge router. There is no direct 
> > host-to-host communication allowed between different subscriber
> > lines.
> 
> Will edge routers send redirects when "neighbors" are sending traffic
> to each other? Or will the Edge Router become a performance bottleneck
> when lots of traffic going through it is sent right back out on its
> incoming interface?
> 

The only reason to hair pin traffic through the edge router is so that
the edge router can act as a policy enforcement point or billing point.

While a lot of SPs would want that, others may not - with one reason
being that if the edge router is geographically remote (as is
commonly the case here in .au), then backhaul bandwidth between the
ANs and the Edge Router has to be provisioned for this inter-customer
traffic. SPs may consider this traffic trivial enough that it only
wants to bill for traffic entering or leaving the aggregation network
via the edge router, ignoring traffic that stays within it. I think
this scenario also creates a need for a prefix-redirect, where the
edge-router, fully aware of the prefixes residing behind the customer's
Residential Gateways, can send a prefix redirect directing one RG that
it is a link layer peer of the RG that the prefix covering the
destination it is trying to reach, and therefore it can send traffic
directly to the RG. There'd be some security issues to address, however
ANs are already performing a lot of "layer violation" traffic
inspection and policy enforcement, so I think it's unlikely that these
additional mechanisms would be much of a burden.

Regards,
Mark.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Sep 2010 11:30:33 -0400

Hi Shree,
   Thanks for the comments. Please find responses inline.

> Please see detailed comments below..

Right. The BBF deployment will have periodic RAs sent to the client with 
the PIOs after the initial RS is sent. The client does not need to 
periodically retransmit the RSs.

> 	Only 3000 unsolicited RA's can be sent before router lifetime expires (this may restrict the scaling).

Yes. It does comply to section 6.2.4 of RFC4861. The scaling issue is 
the same as we face with 1:1 VLANs where we need to send one multicast 
RA per subscriber premise.

> 	Till the edge router runs out of resources..

The subscriber is identified by the line on which the device connects to 
the access node. In this case, all the 8 MAC addresses will end up 
getting tagged with the same Line identification and will end up using 
the same prefix. There will be no resource exhaustion.

> 	Is the packet flooded to all hosts/RG's ? doesn't that defeat the purpose ?

I am working on how to tag the RAs for downstream distribution so that 
the Access Node can perform this filtering. Earlier versions of the 
draft had this feature but it was removed as the WG thought it was not 
necessary. This would require an ND option to be allocated.

> 	how long before options are added so SLAAC becomes an alternative to DHCPv6 ?

The goal is not to come up with an alternative to DHCPv6. The goal is to 
provide backward compatibility for IPv6 hosts that are SLAAC only.

Per host prefixes also are not new and have been used widely in 
non-Ethernet networks (3GPP being a prominent one, where each mobile 
will get a distinct /64 prefix).

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Sep 2010 11:36:19 -0400

Hi Doug,

> neatly here, as well as by other authors in this thread).

As I said in my response to Shree, the goal is to provide support for 
SLAAC-only IPv6 clients. It is not a practical option to require support 
for stateful DHCPv6 for clients that are no longer supported (e.g. XP). 
I agree that going forward, stateful DHCPv6 will be a solution for this 
problem.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Sep 2010 11:45:34 -0400

Hi Mark,

> the edge router can act as a policy enforcement point or billing point.

There are also requirements for lawful intercept on the operators that 
preclude direct communication between subscriber lines.

> additional mechanisms would be much of a burden.

In the specific deployment that this draft is targeted for, user 
isolation is an absolute requirement (R-40 in the TR-101 document and 
explained in RFC4562) and hence it is unclear if prefix redirects would 
be useful.

Thanks
Suresh

---

From: Ralph Droms <[email-masked]>
Date: Wed, 8 Sep 2010 18:17:59 +0200

Nit: seems unlikely to me you will have any XP devices running IPv6-only; if my understanding of the situation is correct, such a device requires manual installation of the IPv6 stack and still requires IPv4 for DNS.

- Ralph

On Sep 8, 2010, at 5:36 PM 9/8/10, Suresh Krishnan wrote:

>> This is the basis of my opposition to adopting the draft (expressed neatly here, as well as by other authors in this thread).
> 
> As I said in my response to Shree, the goal is to provide support for SLAAC-only IPv6 clients. It is not a practical option to require support for stateful DHCPv6 for clients that are no longer supported (e.g. XP). I agree that going forward, stateful DHCPv6 will be a solution for this problem.
> 
> Thanks
> Suresh
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 8 Sep 2010 09:32:47 -0700

Hi Suresh,

Please see two comments below:

Suresh Krishnan wrote:
> > One of the main challenge in implementing the model proposed by the
> > draft is that edge router has no reliable indication if a host (once it has
> > sent an RS) is present on the network or not.

I agree that this is the main challenge.

[...]

> > 	Unlike DHCP there is no mechanism with SLAAC for a host (client)
> >   to renew its address/prefix binding. Relying on host to send a router 
> >   solicitation (as a keep alive) toward edge router is not a viable option.
> >
> Right. The BBF deployment will have periodic RAs sent to the client
> with the PIOs after the initial RS is sent. The client does not need to

Sending periodic RAs with the PIO does not help with the two problems that were pointed out:

- the network does not necessarily know when a host attaches, because the host may timeout sending RSs before the link layer is available to carry these RS's up to the node assigning a prefix. As a result the network does not know that a host attached, does not allocate a prefix, and cannot send a periodic RA that contains the PIO necessary for that hosts to complete SLAAC. The hosts ends up with no connectivity.

- the network never knows when a host detaches, because the host does not send a "goodbye" RS. As a result, if a prefix were allocated by the network for the host, it cannot be returned to a free prefix pool based on signaling from the host. Are you planning to collect unused prefix based on an unused timer? 

--julien

---

From: Doug Barton <[email-masked]>
Date: Wed, 08 Sep 2010 10:29:08 -0700

Ralph,

I use IPv6 in XP so I can confirm your suspicion on both counts. 
IPv6-only is a non-starter for XP.

Suresh,

I understand your goals quite well, which is why I'm opposed to the 
adoption of the draft. :)  Since practically Day 1 of the IPv6 effort 
there has been a movement to make SLAAC/RA a full-featured replacement 
for DHCP, by hook or crook. Please note, I am not impugning _your_ 
motives, but I am opposed to your goal.

Doug

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Sep 2010 14:01:30 -0400

Doug, I am confused by your comments.

Let me describe how I understand the situation.  We claimed, when we 
crafted IPv6, that hosts did not need to use DHCP for address 
assignment.  As such,  many host stacks did not use DHCP for address 
assignment.

Now, operators wanted to offer IPv6 service.  I hope we think that is a 
good thing.  For residential, they looked at what they could count on 
from the hosts.  And some of them concluded that they could not count on 
DHCP, so they designed an architecture around SLAAC.  In other words, 
they ddi what we told them to do.

There are other constraints, and the problems that result are not simple 
to solve.  But they do not matter for your comment.
You seem to be saying that even though the operators did what we told 
them, we should tell them "sorry, you need to redesign your network, and 
you need to assume DHCP based address assignment for all devices in the 
home, even if you can not count on actually having that work??"

Yours,
Joel

On 9/8/2010 1:29 PM, Doug Barton wrote:
>> Nit: seems unlikely to me you will have any XP devices running
>> IPv6-only; if my understanding of the situation is correct, such a
>> device requires manual installation of the IPv6 stack and still
>> requires IPv4 for DNS.
>>
>> - Ralph
>>
>>> SLAAC-only IPv6 clients. It is not a practical option to require
>>> support for stateful DHCPv6 for clients that are no longer supported
>>> (e.g. XP). I agree that going forward, stateful DHCPv6 will be a
>>> solution for this problem.
>>>
>>> Thanks
>>> Suresh

---

From: Doug Barton <[email-masked]>
Date: Wed, 08 Sep 2010 11:16:56 -0700

Your message is very carefully crafted rhetorically, for which I credit 
you with many style points. In terms of standards development less so, 
but I'll take everything you say here at face value just in case.

> crafted IPv6, that hosts did not need to use DHCP for address

Not quite. We claimed, "If you only need a basic configuration (I.e., 
your /64 prefix and default route) to get on line, we have a simple way 
for you to do that without the overhead of DHCP. If you have other 
needs, we'll add them to DHCPv6 as we go along."

> As such, many host stacks did not use DHCP for address assignment.

And in the general case, that works quite well.

Please also note that as far back as 10 years ago there was a fairly 
vocal group of us that were saying things like, "Hey, we _like_ DHCP, 
and don't see the use case for RA;" and, "This RA thing is not going to 
cover all the ways that we use/need DHCP now, so what's the point?" We 
were shouted down by the RA advocates so to a greater or lesser extent 
we stopped trying. Now we've come to yet another use case where RA 
doesn't cut it, but DHCP does.

> Now, operators wanted to offer IPv6 service.  I hope we think that is
> a good thing.

Major style points here btw. :)

> For residential, they looked at what they could count
> on from the hosts.  And some of them concluded that they could not
> count on DHCP, so they designed an architecture around SLAAC.  In
> other words, they ddi what we told them to do.

Eh, not so much actually. See above on what RA can actually be counted 
on for, and what "they" should have heard and understood about it.

Meanwhile, please provide examples of any OS with greater than 5% market 
share that is capable of v6-only operation without the ability to do 
DHCPv6.

[snipping the bit where you put words in my mouth]

Doug

--

---

From: [email-masked]
Date: Wed, 08 Sep 2010 20:18:37 +0200 (CEST)

> they ddi what we told them to do.

On the other hand, some operators have concluded that RA/SLAAC is simply
insufficient. Currently, they need to use RA plus some other mechanism
(for instance DHCP) - but they would *prefer* to use only one mechanism.

Currently, SLAAC/RA alone cannot supply all the necessary parameters
- but  people seem to want to put more and more into RA/SLAAC. That
would be fine by me *if* we can also have a full featured DHCP which
can operate without RA. Yes, I know there's strong political/religious
resistance to doing this - but I believe this is where we're headed...

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Wed, 08 Sep 2010 14:20:15 -0400

Joel,

History is not nearly as simple as you are suggesting...

> assignment.  As such,  many host stacks did not use DHCP for address 

More complicated than that. SLAAC was defined in an RFC years before
DHCP was. This had the obvious result in terms of what was
implemented... (I.e., RFC 2462 was first published in December, 1998,
RFC 3315 was not published until July 2003.)

But yes, there were many who felt that SLAAC was the Holy Grail, and
DHCP should be a relic of IPv4, and that didn't help do the pragmatic
and sensible thing and get DHCP out the door sooner.

> they ddi what we told them to do.

Only partly true. The proposal is to use SLAAC and RAs in an
environment in which basic assumptions on which SLACC and RAs were
built do not hold.

RAs/SLAAC work very well when RAs can be multicast to *all* nodes on a
link, and *all* nodes receive exactly the same information about
prefixes and SLAAC. I.e, your normal subnet model.

What BBF is proposing to do, is to use RAs/SLAAC where each customer
node (i.e, each node on the access network) recieves *different*
configuration information. This means that multicast model on which
RAs were built doesn't work.

This is hardly a "normal" IPv4 subnet model even. (I.e., the nodes
don't share a common prefix, even though they are in the same
broadcast domain.)

> home, even if you can not count on actually having that work??"

I take strong exception with the notion that operators are taking our
"advice" in what they are attempting to do.

It's probably more fair to say that they decided on their own, based
on their (possibly limited) understanding of how IPv6 actually works,
that RAs would work for what they wanted to do.

Thomas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Sep 2010 14:25:30 -0400

The question of whether DHCP should be used to supplement SLAAC< when 
SLAAC is used for address assignment, woudl seem to be a separate 
question.   In, for example, the SAVI work, we have been told repeatedly 
by folks deploying IPv6 that they have to be able to use SLAAC for 
address assignment.  I have not tried to survey the equipment.  Rather, 
I am trying to provide the various operators with solutions that meet 
their reported needs.

To respond here to one of Doug's comments, if 5% of the hsots can not 
use DHCP, then for most operators that would make DHCP address 
assignment a non-starter.  Having 5% of your customers fail, and 
probably consume large amounts of support time figuring out why they 
failed, is simply not workable.

Yours,
Joel

---

From: Ralph Droms <[email-masked]>
Date: Wed, 8 Sep 2010 20:26:59 +0200

Joel - only some operators have decided that they need to allow for the corner case of an IPv6-capable device with no DHCPv6 connected directly to the SP network.  CableLabs took the approach of mandating DHCPv6 for any device connected to a cable SP network; the expectation being that a high percentage of users use some kind of home gateway, and those gateways will all include DHCPv6.  Inside the home, the home gateway provides RAs configured for the hosts to use SLAAC.

I object to expending IETF energy on extensions to the ND protocol architecture to solve a corner case for which DHCPv6 exists as the designed solution.

- Ralph

On Sep 8, 2010, at 8:01 PM 9/8/10, Joel M. Halpern wrote:

> Let me describe how I understand the situation.  We claimed, when we crafted IPv6, that hosts did not need to use DHCP for address assignment.  As such,  many host stacks did not use DHCP for address assignment.
> 
> Now, operators wanted to offer IPv6 service.  I hope we think that is a good thing.  For residential, they looked at what they could count on from the hosts.  And some of them concluded that they could not count on DHCP, so they designed an architecture around SLAAC.  In other words, they ddi what we told them to do.
> 
> There are other constraints, and the problems that result are not simple to solve.  But they do not matter for your comment.
> You seem to be saying that even though the operators did what we told them, we should tell them "sorry, you need to redesign your network, and you need to assume DHCP based address assignment for all devices in the home, even if you can not count on actually having that work??"
> 
> Yours,
> Joel
> 
>

---

From: Doug Barton <[email-masked]>
Date: Wed, 08 Sep 2010 11:29:44 -0700

On 9/8/2010 11:25 AM, Joel M. Halpern wrote:
> question.

I think that's part of what the WG needs to decide, which is why I (and 
now others) have voiced an opinion about it.

> In, for example, the SAVI work, we have been told repeatedly
> address assignment. I have not tried to survey the equipment. Rather, I
> am trying to provide the various operators with solutions that meet
> their reported needs.

Sometimes what people think they want is not what they really need. Any 
good project manager knows that. :)

> assignment a non-starter. Having 5% of your customers fail, and probably
> consume large amounts of support time figuring out why they failed, is
> simply not workable.

You're begging the question. I asked for examples, which if they exist 
might alter my opinion. But you have to find the examples first.

Doug

--

---

From: [email-masked]
Date: Wed, 08 Sep 2010 20:35:25 +0200 (CEST)

> don't share a common prefix, even though they are in the same

There are also operators who use a 1:1 VLAN model, i.e. each customer
in its own broadcast domain. RAs cannot be sent in one nice multicast
message to all customers - and even if they could, each host would
need a different default gateway.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Sep 2010 14:56:55 -0400

Hi Ralph,

> Nit: seems unlikely to me you will have any XP devices running IPv6-only; if my understanding of the situation is correct, such a device requires manual installation of the IPv6 stack and still req…

You are absolutely right. The XP devices are SLAAC-only for IPv6 as I 
said, but they are dual-stacked. So even in the absence of IPv6 
connectivity they will still have IPv4 connectivity.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Sep 2010 15:00:21 -0400

Hi Julien,

> - the network does not necessarily know when a host attaches, because the host may timeout sending RSs before the link layer is available to carry these RS's up to the node assigning a prefix. As a…

Correct. There needs to be some work done in BBF to convey the 
information about the line coming up from the AN to the Edge Router.

> - the network never knows when a host detaches, because the host does not send a "goodbye" RS. As a result, if a prefix were allocated by the network for the host, it cannot be returned to a free p…

Prefixes are never "reclaimed" in SLAAC anyway. The Router will keep 
advertising the prefix on the link no matter if there are any other 
hosts on it or not. The prefix stays assigned to the link.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Sep 2010 15:06:20 -0400

Hi Doug,

> share that is capable of v6-only operation without the ability to do 

I don't think anybody here claimed IPv6-only operation. The BBF network 
in question is dual-stacked and the clients are expected to be 
dual-stack as well.

Thanks
Suresh

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 8 Sep 2010 22:16:17 +0200

>> - the network does not necessarily know when a host attaches, because the
>> host may timeout sending RSs before the link layer is available to carry
>> these RS's up to the node assigning a prefix. As a result the network does
>> not know that a host attached, does not allocate a prefix, and cannot send a
>> periodic RA that contains the PIO necessary for that hosts to complete
>> SLAAC. The hosts ends up with no connectivity.
>>
>
> Correct. There needs to be some work done in BBF to convey the information
> about the line coming up from the AN to the Edge Router.
>
>
> Well, actually that work (line up/down info between AN and edge router) has
already been done (and in the IETF too) by the ANCP WG. That however by
itself is not sufficient, in that there needs to be a destination address of
a data plane device eg  the MAC of a CPE, to send the RA packets to. An
alternative "solution" would naturally be to throw away the regular ethernet
forwarding paradigm on an between the Access-Node and Edge Router by
inventing and deploy a new dataplane based around forwarding of line-id
addresses. At this point one could well say that the cure is worse than the
problem it tries to solve...

-Woj.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 8 Sep 2010 16:11:43 -0500

>From my perspective, I find this situation to be fundamentally intolerable, but easy to fix.

XP cannot be expected to only need IPv6 for simple in-home use. And at the same time, not much more than simple in-home use can really be expected to work correctly with SLAAC alone.

Count me among those who want DHCPv6 to be supported in client OSs.

My inclination would be to require DHCPv6 support, and to either have Microsoft provide it via Windows Update, or use third party software. Like in the old days.

Industrial and military uses tend to stick with stable, tried and true OSs. So XP won't go away overnight. I suppose that by the same token, nor will IPv4, for precisely this sort of reason.

Bert

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Sep 2010 06:59:51 +0930

On Wed, 8 Sep 2010 11:45:34 -0400

> preclude direct communication between subscriber lines.

I think it is very very likely that some ANs have the mechanisms to do
capture traffic at the point of connection of the customer, with
those mechanisms not constrained by the VLANs/PVCs that are configured.

> explained in RFC4562) and hence it is unclear if prefix redirects would 

Sure. This was more of a comment about slightly more general scenarios
and a slightly more general mechanism.

I'd really like to see the BBF / ADSL industry take more advantage of
ethernet, not use it just to reduce costs. A lot of effort has and is
going into making it point to multipoint in residential access
scenarios (i.e. make it fit an ATM connectivity model), yet there would
be tangible advantages in also having options to truly take advantage of
it's multipoint capabilities, such as the scenario I suggested.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Sep 2010 09:54:12 +1200

> resistance to doing this - but I believe this is where we're headed...

Firstly, I'm all in favour of fully featured DHCPv6 and I expect that it
will be included in all successful v6 stacks, simply because there will
be sites and providers that require it. I don't think the IETF needs
to worry about that much, though I'd certainly see it as a MUST
implement if I was a vendor.

But there are very strong reasons that are neither political nor
religious for retaining SLAAC as the default mechanism for starting
up a network, and I think that has to include RAs to make any sense
whatever. Basically, we need zeroconf networks to be viable. I can't
see why that would be a problem for an operator who uses DHCPv6 as their
supported mechanism.

I don't see any technical case for expanding SLAAC/RA beyond
RFC 5006, and that's already in hand.

    Brian

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 8 Sep 2010 16:43:04 -0700

> don't share a common prefix, even though they are in the same

Right, what we essentially have here (and what has been referred to as "N:1 VLAN allocation model") is a point-to-multipoint link model that constitutes a broadcast domain but where there is a desire to advertize different prefixes to different endpoints (CPEs at the multipoint end.) 

The 16ng WG has managed to do so something similar over the IEEE 802.16 link layer that is documented in RFC 5121. In 16ng however, from the perspective of the edge router, each of branch of the point-to-multipoint 802.16 link layer appears as a distinct link to the IP layer, thanks to the use of distinct, per-endpoint, IEEE 802.16 connection IDs and tunneling between the edge router and the aggregation point. Because there is a different link between the edge router and the endpoints, the edge router can multicast unsolicited RAs containing a per-endpoint prefix on each of the links.

In BBF this cannot be done because there is no tunneling between the access node and the edge router, and thus the edge routers sees only one link.

Maybe it is time to write an "Issues with Per-Endpoint Subnet Link Model on Point-to-Multipoint Links" that would explains the caveats that exists, ala RFC 4903.

--julien

---

From: Karl Auer <[email-masked]>
Date: Thu, 09 Sep 2010 11:23:12 +1000

> IPv6-only is a non-starter for XP.

You do need IPv6 and IPv4 on the XP host, but the host can exist in an
IPv6-only network if you put an IPv6-capable nameserver on the host and
let the host use that. It is only XP's own resolver that is limited to
IPv4.

As to IPv6 requiring manual installation, I'm not sure. When I set XP up
in a VM, it seems to be IPv6-aware out of the box. Maybe it depends on
the SP level? I am not a Windows sort of guy, so could well be wrong.

Given that solving the DNS issue requires massive intervention on the
host, actually getting IPv6 running is probably a minor problem :-)

Regards, K.

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

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Sep 2010 07:43:35 +0200 (CEST)

On Thu, 9 Sep 2010, Brian E Carpenter wrote:

> I can't see why that would be a problem for an operator who uses DHCPv6 
> as their supported mechanism.

I'm sure there are a lot in the IETF that agrees with you that they don't 
understand why it's a problem, because the IETF has historically been 
totally uninterested in security in development.

If one uses RA, then things like RA guard, RA inspection etc (SAVI) has to 
work to do this securely in L2 aggregation. If DHCPv6 could be used alone, 
then no intelligence for RA needs to be done, you just filter/drop it and 
a lot of problems goes away.

It's the lack of understanding about deployment issues in the IETF that is 
making IPv6 hard to deploy for ISPs today. We're not lazy, it's just that 
15 years of non-work on security for IPv6 has to be done in a few years, 
this took 5+ years to get right on IPv4 (and it's still not done right by 
a lot of vendors, most likely due to lack of standards).

SAVI is a great step forward, but it seems quite complicated due to the 
fact that the issues SAVI tries to adress doesn't seem to have been 
considered at all when IPv6 (or IPv4) was designed.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Thu, 9 Sep 2010 15:53:26 +0530

Suresh,

There are still unanswered questions..

Comments inline ...

--
Shree

>From: Suresh Krishnan [mailto:[email-masked]]

[..snip..]

>periodically retransmit the RSs.

[Shree]  The draft requires edge router to remember hardware address of each node to unicast the RA's. 
	With no reliable feedback from end device to signal if it's on or off the network, how long should the 
	edge router remember the hardware address to LIO Prefix binding ? 
	
	Time out's are not an option since device may not send another RS till it resets etc.

	The most logical approach would be for edge router to use Neighbor Discovery before timing out the binding.
	But even that's not 100% conclusive e.g. when a DSL link is down, ND will fail and edge router will timeout it's binding
	However end point will still have the binding, and with no router advertisement will eventually expire the address.
	But there is nothing in spec which says end point should resend a RS to re-create this binding..

	a catch-22 sort of situation..

>RA per subscriber premise.

[Shree] The draft callsfor one RA to be unicast per IPv6 end node (L2 hardware address), so if
There are 6 devices connecting from a subscriber premises (RG is bridged) the scaling is reduced
Compared to 1:1 VLAN. 

Is there a need to relax MinRtradvInterval requirement for L2Unicast messages ?

>> 	a delayed DoS e.g. where a malicious node sends a router solicit (with 8
>different MAC addresses) waits for 30 mins

[Shree] The binding referred was edge router storing hardware address from each RS received.
	 This still holds true as possible DoS attack, since there is no reliable mechanism to 
	 Cleanup MAC addressed stored to unicast the RA.

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Sep 2010 19:59:16 +0930

On Thu, 9 Sep 2010 07:43:35 +0200 (CEST)
Mikael Abrahamsson <[email-masked]> wrote:

> It's the lack of understanding about deployment issues in the IETF 

So why aren't operators involving themselves more? I've seen a number
of invitations for feedback and comments on IETF in a variety of fora
such as nanog and other mailing lists etc., yet rarely does it seem to
result in very much participation. Don't they know the IETF price of
admission is nothing, other than a bit of time? Don't they realise that
following and participating in the IETF gives them an opportunity to be
able to both see what may be coming operationally in the future, and
possibly influencing it was well?

"What we’re saying today is that you're either part of the solution or
you’re part of the problem." - Eldridge Cleaver

>that is 

Unfortunately I think the fundamental issue that SAVI is trying to
address is that if you're on a broadcast shared access media 
e.g. a LAN, you have to place a level of trust in your peers that
they're not going to disrupt the shared resource, intentionally or
otherwise. They have a shared interest in you not doing it to them
either.

SAVI won't and can't complete this problem - nor can SeND either. 

Ultimately I think if you cannot trust your link layer peers at all
then you can't have the benefit of sharing it with them. They have to
be completely quarantined from each other, via e.g. VLANs, PPPoE
etc., with access to the rest of the network via a policy enforcement
and vetting device of some sort i.e. a router doing more than just
forwarding packets.

SAVI and things like SeND are beneficial halfway measures, avoiding
full quarantining.

Regards,
Mark.

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Thu, 9 Sep 2010 16:16:13 +0530

Suresh,

>provide backward compatibility for IPv6 hosts that are SLAAC only.

[Shree]  Understand the goal, 
but with no way to distinguish between "SLAAC only" V/s "DHCP capable hosts"  
the natural choice would be to opt for lowest common denominator i.e. "SLAAC only" mechanism.

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Sep 2010 19:46:04 +0900

On Sep 9, 2010, at 7:29 PM, Mark Smith wrote:

> SAVI and things like SeND are beneficial halfway measures, avoiding full quarantining.

I would generally agree.

Just like being at a cocktail party, there is no way to know just how looped a neighbor is or how it will behave in that condition. What SeND tries to do is ensure that a system uses exactly one EID on an interface (if it has several prefixes, it will have several addresses, but the lower 64 bits will be what it has a key for). What SAVI tries to do is ensure that if one system is using an address, another system doesn't try to use it also. Only works in switched networks, as it is the switch that imposes the control. On the other hand, consider privacy addresses; one could easily imagine a system periodically changing its EID, or using more than one at a time, perfectly legally. SEND would preclude that, SAVI allows for it. BTW, both apply to conversations on-LAN, the kind that ONLY go through the switch.

Does that solve all problems? obviously not. It does limit the impact of certain classes of attacks. IP Source Guard, a feature from my company and also from some others, is essentially the same thing for IPv4, and appears to be popular in certain quarters.

Upstream, there are two things that can be done in a router. BCP 38, whether the uRPF or filtered version, is obviously one. If one uses a registered address model in IPv6 Neighbor Discovery (eg, if a router on your LAN will only forward your packets if it has a neighbor relationship with you in the subnet in question), that similarly forces a certain level of decorum on the host.

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Thu, 9 Sep 2010 17:15:48 +0530

>> - the network never knows when a host detaches, because the host does not
>send a "goodbye" RS. As a result, if a prefix were allocated by the network for the
>host, it cannot be returned to a free prefix pool based on signaling from the host.
>Are you planning to collect unused prefix based on an unused timer?
>

[Shree] when does the router stop sending unicast RA's to a MAC address ?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Sep 2010 14:45:21 +0200 (CEST)

On Thu, 9 Sep 2010, Mark Smith wrote:

> So why aren't operators involving themselves more?

I don't know. I've been involving myself in IETF the past year or so, but 
it's not something I can spend huge amounts of time on.

> I've seen a number of invitations for feedback and comments on IETF in a 
> variety of fora such as nanog and other mailing lists etc., yet rarely 
> does it seem to result in very much participation. Don't they know the 
> IETF price of admission is nothing, other than a bit of time?

It's the bit of time that is the problem. It's also a competence problem.

I also think quite a lot of people get ticked off when they come to the 
IETF and says "we like DHCPv4, we'd like IPv6 to work the same way" and 
then being told "you're wrong".

> Don't they realise that following and participating in the IETF gives 
> them an opportunity to be able to both see what may be coming 
> operationally in the future, and possibly influencing it was well?

Correct, but a lot of the IETF is ruled by academic people or people 
working in design who haven't seen any operational network in a long time.

> address is that if you're on a broadcast shared access media e.g. a LAN, 
> you have to place a level of trust in your peers that they're not going 
> to disrupt the shared resource, intentionally or otherwise. They have a 
> shared interest in you not doing it to them either.

*sigh*

I don't know where to start. There has been a lot of work done in IPv4 
space to make it deployable for ISPs with some intelligence in the L2 
network. These functions for IPv6 is seriously lacking. SAVI tries to do 
some of them. IPv4 can be made to be completely secure with ETTH and L2 
intelligence (DHCP inspection) and there are millions of people connected 
this way in the world. IPv6 deployment in these networks is hard due to 
reasoning like you're doing.

> SAVI and things like SeND are beneficial halfway measures, avoiding full 

I don't agree. Full quarantining is expensive and one definitely wants to 
avoid it, it's more cost efficient to share L2 but do other things to make 
sure people can't source traffic they shouldn't.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Sep 2010 14:48:02 +0200 (CEST)

On Thu, 9 Sep 2010, Fred Baker wrote:

> Does that solve all problems? obviously not. It does limit the impact of 
> certain classes of attacks. IP Source Guard, a feature from my company 
> and also from some others, is essentially the same thing for IPv4, and 
> appears to be popular in certain quarters.

Exactly. DHCPv4 inspection, forced-forwarding etc, all these make IPv4 
deployable in low-cost L2 switch environment. This is the reason the same 
ISPs deploying the above would like to run completely without RAs (or at 
least block RAs from all customer ports) and rely completely on DHCPv6 for 
address hand-out, because then the L2 device can inspect this and 
implement filters.

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Sep 2010 22:05:40 +0900

On Sep 9, 2010, at 9:48 PM, Mikael Abrahamsson wrote:
> Exactly. DHCPv4 inspection, forced-forwarding etc, all these make IPv4 deployable in low-cost L2 switch environment. This is the reason the same ISPs deploying the above would like to run completely without RAs (or at least block RAs from all customer ports) and rely completely on DHCPv6 for address hand-out, because then the L2 device can inspect this and implement filters.

In context, you might want to read

http://tools.ietf.org/html/draft-ietf-savi-dhcp
  "SAVI Solution for DHCP", Jun Bi, Jianping Wu, Guang Yao, Fred Baker,
  7-Sep-10

http://tools.ietf.org/html/draft-ietf-savi-fcfs
  "FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally
  Assigned Addresses", Erik Nordmark, Marcelo Bagnulo, Eric Levy-Abegnoli,
  12-Jul-10

http://tools.ietf.org/html/draft-ietf-savi-send
  "SEND-based Source-Address Validation Implementation", Marcelo Bagnulo,
  Alberto Garcia-Martinez, 13-May-10

We're not limited to controlling a host to a DHCP-assigned address; we can also observe the device's behavior and protect addresses it allocates using SLAAC and SEND.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Sep 2010 15:11:10 +0200 (CEST)

On Thu, 9 Sep 2010, Fred Baker wrote:

> We're not limited to controlling a host to a DHCP-assigned address; we 
> can also observe the device's behavior and protect addresses it 
> allocates using SLAAC and SEND.

Yes, I know, but for an ISP who wants to know what end-entity has an IP 
address at any given time, the only practical way to use SLAAC is to have 
each customer in their own /64, and then it's not really a problem because 
it's a subnet of its own.

It's when you want to share a subnet with multiple DHCPv6(-PD)-handouted 
IP addresses and routed subnets it becomes a bit more complicated. That 
situation is what I was referring to.

SLAAC is fine for home networks (and some enterprise networks).

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 9 Sep 2010 09:17:23 -0400

Hi Ralph

I look at this where we have hosts that are SLAAC based only as Suresh has noted and are directly connected to the Edge Router. In this case we have hosts that connect via SLAAC as is typically the case for unmanaged devices. In the case of these hosts behind a Routed RG that do SLAAC and not DHCPv6. In the case where these hosts are bridged through the RG either selectively or the RG is L2 they still use SLAAC for address configuration. 

I think we need to ensure that we don't force Service Providers down a path that they are reducing the flexibility in how they should deploy their network and services. What we need to do is ensure we have options for the SP to choose the most appropriate solution that fits their network deployment and business needs. 

Im not here to compare SLAAC vs DHCP, that's not what the draft does and that's not the intention.....as I see both protocols existing and having merits for different deployment needs......its not my place to tell O.S vendors, CPE vendors, SP's and home users how best to suit their needs, its better to provide options, and embrace that we have SLAAC and will be used in numerous deployment cases.

I don't see these as corner cases Ralph there are a significant number of SP's/subscribers whom connect to DSL networks in this manner and as we want these SP's to embrace IPv6 we need to remove as many "roadblocks" as possible.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: September-08-10 2:27 PM
To: Joel M. Halpern
Cc: Narten Thomas; IPv6 WG Mailing List; Suresh Krishnan
Subject: Re: New version available (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

- Ralph

On Sep 8, 2010, at 8:01 PM 9/8/10, Joel M. Halpern wrote:

>> there has been a movement to make SLAAC/RA a full-featured 
>> replacement for DHCP, by hook or crook. Please note, I am not 
>> impugning _your_ motives, but I am opposed to your goal.
>> 
>> 
>> Doug
>> 
>> 
>>>>>> One SLAAC is defined to do functionality similar to DHCP 
>>>>>> (including per host prefixes/options) how long before options are 
>>>>>> added so SLAAC becomes an alternative to DHCPv6 ?
>>>>> This is the basis of my opposition to adopting the draft 
>>>>> (expressed neatly here, as well as by other authors in this thread).
>>>> 
>>>> As I said in my response to Shree, the goal is to provide support 
>>>> for SLAAC-only IPv6 clients. It is not a practical option to 
>>>> require support for stateful DHCPv6 for clients that are no longer 
>>>> supported (e.g. XP). I agree that going forward, stateful DHCPv6 
>>>> will be a solution for this problem.
>>>> 
>>>> Thanks
>>>> Suresh

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Sep 2010 22:27:56 +0900

> Exactly. DHCPv4 inspection, forced-forwarding etc, all these make IPv4 deployable in low-cost L2 switch environment. This is the reason the same ISPs deploying the above would like to run completel…

BTW, let me ask a question that came up recently "back at the ranch".

As you no doubt know, there has been discussion on NANOG re RFC 5157 "IPv6 Implications for Network Scanning", which basically asserts that nobody in their right mind would address-scan an IPv6 network. Guess what, someone did, demonstrating that as smart as some hacks are, some of them are a little out of touch. BTW, there are ways to optimize an address scan, for the more-clueful hack (draft-baker-v6ops-greynet), and even if one can't actually scan the addresses, one can use a scan to attack other things.

A suggestion was made that the algorithms discussed in

http://tools.ietf.org/html/draft-ietf-6lowpan-nd
  "Neighbor Discovery Optimization for Low-power and Lossy Networks", Zach
  Shelby, Samita Chakrabarti, Erik Nordmark, 2-Aug-10

might be extended to generalized networks. In short, if a host wants a router to carry packets for it, it needs to register its IPv6 address (and, on an Ethernet, its MAC address) with the router, and the router might literally ensure the correspondence of the MAC address and the source IPv6 address, failing which it silently drops the packet. As a result, the router never sends an NS, except to a neighboring router, and hosts that do bad things of this category get blissfully ignored.

Could a host application still spoof packets? Yes, but it has a more demanding process to go through - it has to register the "spoofed" address with the router, meaning that if it does so at a high rate someone's likely to notice.

The argument for ND as currently defined is in essence to permit hosts to readily generate and change addresses, for scaling purposes. There is a security value in the sense that a host can hide in plain sight - if it is subjected to an attack and changes its address (pick a reason), the attack doesn't come to it any more, at least not for a while.

The upside of DHCP is that it gives the operator a great deal of control. My observation, though, is that operators generally cede that to more random processes that run on routers or other equipment. I don't see the argument for DHCP in context - more for stateless DHCP, which updates parameters on all of the hosts in a subnet. Would this kind of a service be interesting/acceptable for operators?

---

From: [email-masked]
Date: Thu, 09 Sep 2010 15:45:16 +0200 (CEST)

> The upside of DHCP is that it gives the operator a great deal of control. My observation, though, is that operators generally cede that to more random processes that run on routers or other equipme…

One comment, not directly related to the 6lowpan-nd draft: There are
countries where service providers are required to know which customer
is using a particular (global) address at a particular time - we need
to be able to supply this information to the police on request. This
is one of the reasons why the control of (stateful) DHCP is useful,
and where "random processes that run on routers or other equipment"
make life harder.

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Sep 2010 23:14:42 +0930

On Thu, 9 Sep 2010 15:11:10 +0200 (CEST)

> it's a subnet of its own.

I don't know about other vendors, however Cisco have a model of SLAAC
address assignment where a single /64 is used for address assignment to
PPP sessions, with the /64 announced in the RA PIO. In effect the PPP
connections become part of a NBMA point to multipoint topology. RADIUS
reports this assignment (as it will with individual /64s per PPP
session too from within a pool).

> situation is what I was referring to.

I'm not really sure I understand the scenario you're describing. I'm
having no trouble with RA + SLAAC + DHCPv6-PD, static and dynamic
assignments of /64 for PPP session and delegated prefixes via
DHCPv6-PD.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 9 Sep 2010 10:17:45 -0400

> it's not something I can spend huge amounts of time on.

because, like most operations folks, you have an actual job keeping
actual users working on the actual network...

I too fall into the same boat as Mikael here... I have a real job that
takes up my 8+ hours a day of work time, and then ... 'volunteer' jobs
that take up the remains. Not everyone in ops has time to do this sort
of work, the ROI for ops folks wrt IETF is... difficult to justify to
management when lower staffing levels, higher work loads and less
interest in 'frivolous time wasting' is the new black.

>> variety of fora such as nanog and other mailing lists etc., yet rarely does
>> it seem to result in very much participation. Don't they know the IETF price
>> of admission is nothing, other than a bit of time?

it's far more than 'a bit of time'... speaking as someone who's been
trying to do ietf things for the better part of 4 years (admittedly
sometimes realwork intrudes on my ietf interludes).

> I also think quite a lot of people get ticked off when they come to the IETF
> and says "we like DHCPv4, we'd like IPv6 to work the same way" and then
> being told "you're wrong".

yes (though this is getting better, for the DHCPv6 case at least. For
other things... still more head+wall is required)

>> Don't they realise that following and participating in the IETF gives them
>> an opportunity to be able to both see what may be coming operationally in
>> the future, and possibly influencing it was well?
>
> Correct, but a lot of the IETF is ruled by academic people or people working
> in design who haven't seen any operational network in a long time.
>
>> Unfortunately I think the fundamental issue that SAVI is trying to address
>> is that if you're on a broadcast shared access media e.g. a LAN, you have to
>> place a level of trust in your peers that they're not going to disrupt the
>> shared resource, intentionally or otherwise. They have a shared interest in
>> you not doing it to them either.
>
> *sigh*
>
> I don't know where to start. There has been a lot of work done in IPv4 space
> to make it deployable for ISPs with some intelligence in the L2 network.
> These functions for IPv6 is seriously lacking. SAVI tries to do some of
> them. IPv4 can be made to be completely secure with ETTH and L2 intelligence
> (DHCP inspection) and there are millions of people connected this way in the
> world. IPv6 deployment in these networks is hard due to reasoning like
> you're doing.

this is a case where 'listen to how the network is operated today,
please.' is required I think. There are business reasons that things
are done as they are in real networks supporting many millions of
people.

> sure people can't source traffic they shouldn't.

"which is available today in production networks using ipv4, and until
these capabilities are available in IPv6 as well, there will continue
to be less deployment than we all want." (I think was the end of the
sentence/intent there)

As an aside, railing against "why are not more operators
participating" is hard to stomach when the next version of sentence
is: "you are doing it wrong because that large network you run already
can't possibly work that way in ipv6-land".

-chris
(thanks mikael!)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Sep 2010 17:09:53 +0200 (CEST)

On Thu, 9 Sep 2010, Mark Smith wrote:

> reports this assignment (as it will with individual /64s per PPP session 
> too from within a pool).

PPP is not used here. There are numerous different deployment models, PPP 
is an expensive one that should be avoided unless there is serious use for 
it.

> assignments of /64 for PPP session and delegated prefixes via

ETTH doesn't include PPP for me. Tunneling is expensive.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Sep 2010 17:21:46 +0200 (CEST)

> BTW, let me ask a question that came up recently "back at the ranch".

To be really honest, I don't understand what the question is in the text 
you wrote.

But if I understood correctly DHCPv6 derived values would be used to 
populate IP/MAC tables instead of actually using ND. I think this is an 
excellent idea for ISP<->customer links, and I would also like to see 
packets droppped if the IP/MAC combination doesn't match (which your text 
indicated was the idea).

Basically today if we were to deploy IPv6 in ETTH, I'd imagine RA being 
used to advertise routing. We would filter RAs from customers. We would 
not advertise a prefix on-link, so all traffic between customers would be 
going thru the ISP router, and we would hand out adresses/prefix via 
DHCPv6(-PD). We would need L2 switches involved to understand all these 
mechanisms and enforce this policy as they do L2 switching.

That is the closest thing I've been able to come up with in IPv6-land that 
matches what we already do in IPv4-land.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 9 Sep 2010 12:16:21 -0400

> actual users working on the actual network...

so... more coffee and a lunch later... I did forget to say that as
near as I can tell, or from my prospective, the drum of 'why arent
more ops folks at ietf' has gotten better over the last while (3-4
years which is as long as I've been able to pay attention so far).

The drum of 'but we never get what we want out of the ietf!!' from ops
folks also has gotten better.

My note prompted at least (so far) one private note that reminded me
that yelling sometimes doesnt' get what I want :( In general the
process/outcome from IETF (for v6 things) has gotten better not worse,
some bumps still to iron out though (which is expected).

-chris

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Sep 2010 18:39:32 +0200 (CEST)

> some bumps still to iron out though (which is expected).

There are absolutely improvements to be had. Both the IETF and the ops 
community could improve a lot in its communication, but I don't see this 
improving radically soon. A lot of ISPs rely on their vendors to do the 
right thing, the vendors might rely on other vendors to do the design 
work, and vendors might internally within themselves squabble what should 
be done, and academics are somewhere up in the air doing whatever is hot 
in their granting committee at the time.

I think a lot could be done by even more announcements of new drafts on 
the ops list and asking for comments there, that might lure more people 
onto the IETF lists as well.

Doing executive summaries about what the drafts/RFCs contain would be nice 
as well, would probably also increase the amount of people reading them.

At least the IETF doesn't have pay walls, I definitely prefer the IETF 
model compared to ITU. Starting to comment and contribute on IETF lists is 
quite easy if you want to...

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 9 Sep 2010 13:51:36 -0400

Hi Woj,

On 10-09-08 04:16 PM, Wojciech Dec wrote:
>         - the network does not necessarily know when a host attaches,
>         because the host may timeout sending RSs before the link layer
>         is available to carry these RS's up to the node assigning a
>         prefix. As a result the network does not know that a host
>         attached, does not allocate a prefix, and cannot send a periodic
>         RA that contains the PIO necessary for that hosts to complete
> Well, actually that work (line up/down info between AN and edge router) 
> has already been done (and in the IETF too) by the ANCP WG. That however 
> by itself is not sufficient, in that there needs to be a destination 
> address of a data plane device eg  the MAC of a CPE, to send the RA 
> packets to. An alternative "solution" would naturally be to throw away 
> the regular ethernet forwarding paradigm on an between the Access-Node 
> and Edge Router by inventing and deploy a new dataplane based around 
> forwarding of line-id addresses. At this point one could well say that 
> the cure is worse than the problem it tries to solve...

Thanks for the pointer to ANCP. It was very useful. I also don't think 
that it makes sense to invent a line-id based dataplane between the Edge 
Router and the AN. But I think it is entirely viable to do line-id based 
filtering on the AN.

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 9 Sep 2010 13:55:10 -0400

Hi Julien,

> Maybe it is time to write an "Issues with Per-Endpoint Subnet Link Model on Point-to-Multipoint Links" that would explains the caveats that exists, ala RFC 4903.

This sounds like a good idea. I think identifying the generic issues 
with this kind of usage will be invaluable. I am looking forward to read 
and contribute.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 9 Sep 2010 14:47:25 -0400

Hi Shree,

> There are still unanswered questions..

The goal is to use some sort of indication from the AN as to when the 
DSL link is up or down (perhaps using ANCP as Woj suggested) to 
determine when to start and stop sending periodic RAs.

> There are 6 devices connecting from a subscriber premises (RG is bridged) the scaling is reduced

Depends on the mechanism you use to distribute the unsolicited multicast 
RAs. The scheme I was thinking of for the next version of the draft does 
not have this issue. There will be one multicast RA per subscriber line 
and not per subscriber device.

> Is there a need to relax MinRtradvInterval requirement for L2Unicast messages ?

I am not sure there is a need to do that. For WiMAX (16ng) it was 
necessary to do that in order to avoid waking up the dormant nodes. In 
this case the clients will most likely not go dormant.

> 	 Cleanup MAC addressed stored to unicast the RA.

The MAC address of the client is used as the destination address only 
for the solicited RA and does not need to be remembered for future use.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 9 Sep 2010 14:49:46 -0400

Hi Shree,

> the natural choice would be to opt for lowest common denominator i.e. "SLAAC only" mechanism.

Not necessarily. In most deployment scenarios we know the "host" is a 
routed residential gateway and the SDOs usually specify what is required 
on them. e.g. in BBF, the routed RG will certainly have a DHCPv6 client 
on it and hence we can assume that it will be present. So we narrow down 
the uncertainty to a few scenarios that are not extremely common.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 9 Sep 2010 14:50:38 -0400

Hi Shree,

> [Shree] when does the router stop sending unicast RA's to a MAC address ?

When it gets a notification from the AN that the specific DSL line is down.

Thanks
Suresh

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 9 Sep 2010 13:38:33 -0700

Hi Fred,

Two minor clarification regarding SeND below:

Fred Baker wrote: 
> Just like being at a cocktail party, there is no way to know just how
> looped a neighbor is or how it will behave in that condition. What SeND
> tries to do is ensure that a system uses exactly one EID on an
> interface (if it has several prefixes, it will have several addresses,
> but the lower 64 bits will be what it has a key for).

SeND does not restrict a given system to use exactly one EID on an interface. A SeND node can configures as many CGA as it wants per interface. SeND will then ensures that when a node does so and configures a CGA address, no other node can subsequently redirect traffic sent to that CGA address by spoofing ND signaling. Within a given subnet prefix, different CGAs can be configured out of multiple public-private key pairs, or out of the same public-private key pair, using different CGA Modifier values in the generation algorithm. 

>                                                        What SAVI tries
> to do is ensure that if one system is using an address, another system
> doesn't try to use it also. Only works in switched networks, as it is
> the switch that imposes the control. On the other hand, consider
> privacy addresses; one could easily imagine a system periodically
> changing its EID, or using more than one at a time, perfectly legally.
> SEND would preclude that, SAVI allows for it. BTW, both apply to
> conversations on-LAN, the kind that ONLY go through the switch.

As above, SeND would not preclude a system to periodically change its EID. It can do so by generating new public-private key pairs, or simply changing the CGA Modifier value used in the generation. Of course if privacy is the motivation to do so, it might be better to change the public-private key pair as well as otherwise on-link eavesdroppers would be able to link together successive CGAs based on the same public-private key pair being used to generate them and to sign ND signaling. (and one would also need to periodically change its L2 address if "linkability" is of concern...)

--julien

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Sep 2010 09:44:01 +1200

On 2010-09-09 17:43, Mikael Abrahamsson wrote:
>> I can't see why that would be a problem for an operator who uses
>> DHCPv6 as their supported mechanism.
> 
> I'm sure there are a lot in the IETF that agrees with you that they
> don't understand why it's a problem, because the IETF has historically
> been totally uninterested in security in development.

That really hasn't been true for many years now. But as you said yourself
a few hours later:

On 2010-09-10 01:11, Mikael Abrahamsson wrote:
...
> SLAAC is fine for home networks (and some enterprise networks). 

That's exactly what (IMHO) we need to preserve, which has the side
effect that it's going to be the default mechanism for IPv6 nodes
shipped out into the SOHO market. I expect DHCPv6 to be the default
for nodes shipped into the ISP and large enterprise market.

   Brian

    Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 10 Sep 2010 07:12:07 +0930

> and where "random processes that run on routers or other equipment"

I don't think this is an issue. RADIUS Accounting can be used (and is)
to report dynamically assigned IPv6 addressing information, just as it
was with IPv4.

The relevant IETF RADIUS attributes are -

Framed-Interface-Id

Framed-IPv6-Prefix

Delegated-IPv6-Prefix

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Sep 2010 14:13:43 +0900

On Sep 10, 2010, at 6:44 AM, Brian E Carpenter wrote:

> That's exactly what (IMHO) we need to preserve, which has the side effect that it's going to be the default mechanism for IPv6 nodes shipped out into the SOHO market. I expect DHCPv6 to be the default for nodes shipped into the ISP and large enterprise market.

That would actually materially surprise me, as the same systems are delivered to both markets. What I observe is that Windows 7, Macintosh, and *nix all default to some variant of SLAAC, and some of them have the ability to be configured for DHCPv6.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Sep 2010 07:34:42 +0200 (CEST)

> That really hasn't been true for many years now. But as you said yourself

I guess we can agree to disagree. Considering SAVI isn't "done" in even 
their basic stuff, my opinion stands firm. IPv6 isn't deployable in a 
bunch of deployment scenarios used today, and that's because most of the 
protocols designed in the IETF hasn't had that part as a design criteria.

It's definitely headed in the correct direction though, but there is still 
a lot of work to be done.

---

From: [email-masked]
Date: Fri, 10 Sep 2010 07:41:03 +0200 (CEST)

> The relevant IETF RADIUS attributes are -

That's fine, *if* your infrastructure is Radius based. On the other
hand, if your infrastructure is DHCP based, it is definitely an issue -
and another stumbling block to the introduction of IPv6.

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 10 Sep 2010 11:52:35 +0200

> is an expensive one that should be avoided unless there is serious use for

While it is true that PPP is not used here, I won't say that PPP should be avoided.
PPP is a valid and widely deployed model in DSL Broadband environment; Broadband Forum has already published TR-187 that explains how to deploy IPv6 with PPP.

In addition in case of bridged Layer 2 RG model, PPP + SLAAC with the /64 announced in the RA PIO is a valid solution.

Best Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: giovedì 9 settembre 2010 17.10
To: Mark Smith
Cc: [email-masked]; Fred Baker
Subject: Re: New version available

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Tina TSOU <[email-masked]>
Date: Fri, 10 Sep 2010 12:00:24 +0200

B. R.
Tina
http://tinatsou.weebly.com

On Sep 10, 2010, at 11:52 AM, Maglione Roberta wrote:

> PPP is a valid and widely deployed model in DSL Broadband  
> environment; Broadband Forum has already published TR-187 that  
> explains how to deploy IPv6 with PPP.
>
> In addition in case of bridged Layer 2 RG model, PPP + SLAAC with  
> the /64 announced in the RA PIO is a valid solution.
>
> Best Regards,
> Roberta
>
Some operators have serious use for PPPoE in large scale. It is a  
tradeoff for them to decide whether it is expensive or not from the  
whole picture point of view.
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente  
> alle persone indicate. La diffusione, copia o qualsiasi altra azione  
> derivante dalla conoscenza di queste informazioni sono rigorosamente  
> vietate. Qualora abbiate ricevuto questo documento per errore siete  
> cortesemente pregati di darne immediata comunicazione al mittente e  
> di provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain  
> privileged information intended for the addressee(s) only.  
> Dissemination, copying, printing or use by anybody else is  
> unauthorised. If you are not the intended recipient, please delete  
> this message and any attachments and advise the sender by return e- 
> mail, Thanks.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Sep 2010 12:10:28 +0200 (CEST)

On Fri, 10 Sep 2010, Maglione Roberta wrote:

> While it is true that PPP is not used here, I won't say that PPP should 
> be avoided. PPP is a valid and widely deployed model in DSL Broadband 
> environment; Broadband Forum has already published TR-187 that explains 
> how to deploy IPv6 with PPP.
>
> In addition in case of bridged Layer 2 RG model, PPP + SLAAC with the 
> /64 announced in the RA PIO is a valid solution.

I didn't say it wasn't valid, I said it should be avoided due to high 
cost. This is my opinion and I stand by it.

My problem is that people seem to think that just because IPv6 deployment 
is fixed in PPP environments, now things are DONE. They are not. There are 
numerous other deployment models in wide use that have not been properly 
adressed yet.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Sep 2010 12:13:46 +0200 (CEST)

On Fri, 10 Sep 2010, Tina TSOU wrote:

> Some operators have serious use for PPPoE in large scale. It is a tradeoff 
> for them to decide whether it is expensive or not from the whole picture 
> point of view.

Yes. I don't see where I said they shouldn't. I said it was expensive, I 
didn't deny there was a lot in use.

It's great that IPv6 over PPP is solved (it was the easy one to solve), 
but we won't deploy PPPoE to our residential ETTH customers just to get 
them IPv6, that is just not a reasonable solution for us.

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 10 Sep 2010 12:21:45 +0200

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]]
Sent: venerdì 10 settembre 2010 12.10
To: Maglione Roberta
Cc: Mark Smith; [email-masked]; Fred Baker
Subject: RE: New version available

> numerous other deployment models in wide use that have not been properly

I didn't say things are done, I just described an alternative model. In addition in my opinion for the migration from PPP to IP Sessions there are still a lot of unsolved issues even with IPv4 Sessions, without talking about IPv6.

Regards,
Roberta

---

From: [email-masked]
Date: Fri, 10 Sep 2010 12:22:55 +0200 (CEST)

> In addition in case of bridged Layer 2 RG model, PPP + SLAAC with the /64 announced in the RA PIO is a valid solution.

Nobody is saying that PPP should be avoided. However, if you have an
existing customer base which is DHCP based, the cost of converting this
to PPP can be very significant (as in: not going to happen). Requiring
PPP in order to use IPv6 (when you already have a DHCP infrastructure
for your IPv4 customers) is a complete non-starter.

---

From: <[email-masked]>
Date: Fri, 10 Sep 2010 12:52:44 +0200

> environment; Broadband Forum has already published TR-187 
> that explains how to deploy IPv6 with PPP.
> 
> In addition in case of bridged Layer 2 RG model, PPP + SLAAC 
> with the /64 announced in the RA PIO is a valid solution.
> 
> Best Regards,
> Roberta

Trying to bring the ball back into the game. 
If I have to run (as network operator) PPP or 1:1 VLAN based access networks and besides that also N:1 VLAN based network access parts than I would nevertheless like to have _one_ common method for provisioning of address/prefix information. 
And since SLAAC is one of the valid mechanisms for doing that (according to WT-187) I'm interested to learn if/how that can also work for N:1 VLANs. And I-D krishnan-6man-rs-mark is describing such an approach. Thats why I'm also interested in that I-D.

Ciao
	Olaf

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Sep 2010 15:59:20 +0300

Some of the discussion has gone into the history of IPv6 design, what 
configuration model was intended by the original designers as the right 
one, and so on. I would suggest that while that's interesting, it may be 
secondary to what we are discussing here.

Suresh wants to support a particular type of a deployment, and it 
doesn't help him if some design is the "right" one or matches with our 
*desires* of what hosts and other devices should be doing or 
implementing. The primary concern should be that we have something that 
works. In particular, we need to worry about what random hosts do in 
these networks, as we cannot dictate what devices will exist in people's 
homes. And we cannot upgrade or change existing implementations. This 
applies both to the problem that started this discussion, i.e., hosts 
giving up on sending RSes but also to their support of DHCPv6. As an 
example, while DHCPv6 is available on Linux, none of the IPv6 Linux 
devices that in my network have come with DHCPv6 on by default. (You can 
of course ask me to change my configs, but asking my mother to do the 
same may not be feasible.)

Host support is important because that is an area where neither the 
IETF, any single vendor, or the DSL operators have any easy way to 
change the situation. But it is of course by no means the only 
constraint. The operators have their issues as well. Even though they 
are in control of their own networks, they probably want to keep their 
underlying L2 network architecture as it is, despite introduction of 
IPv6 or other new features.

Jari

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Sep 2010 15:41:42 +0200 (CEST)

> IPv6 or other new features.

Reading draft-krishnan-6man-rs-mark-06.txt I read this as an "dhcp option 
82"-analogy in the IPv6 SLAAC world. Please correct me if I'm wrong.

We are using the deployment model where this is applicable, and the 
concept seems like it makes sense for using SLAAC in this deployment model 
(I wouldn't really want to, but it might be nice in case of lack of DHCPv6 
support in end nodes).

Some questions though, on the interface on the edge router towards the 
access node (which will receive the tunneled RS packet), it seems there 
should be a recommendation for the edge router to not accept untunneled 
RS, or at least a recommendation that a knob for this behaviour should 
exist? If the interface is only used for customer traffic then there 
should never be an untunneled RS packet if the access node is correctly 
configured?

Also, in 5.1 perhaps there could be a clarification that the new packet is 
still a RS packet, it took me a few readings before I understood that 
part? (did I understand it correctly?) I'm still uncertain, there is text 
about "tunneled packet" and I was looking for the layout of this packet, 
and then I deduced that it's probably RS packet with added option header?

I like that the fields are TLV, makes for easy extension in the future. 
Should perhaps the "option length" be more than 0-255, perhaps 16 bits 
instead of 8?

Has the SAVI WG been involved or seen this draft before? I can see some 
recommendations that they need to implement as well, such as disallowing 
LIO packets from the end customers (drop on floor or replace), rate 
limiting the RS packets per second from the end users, etc.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 10 Sep 2010 16:13:54 +0200

On 10 September 2010 12:52, <[email-masked]> wrote:

> If I have to run (as network operator) PPP or 1:1 VLAN based access
> networks and besides that also N:1 VLAN based network access parts than I
> would nevertheless like to have _one_ common method for provisioning of
> address/prefix information.
> And since SLAAC is one of the valid mechanisms for doing that (according to
> WT-187) I'm interested to learn if/how that can also work for N:1 VLANs. And
> I-D krishnan-6man-rs-mark is describing such an approach. Thats why I'm also
> interested in that I-D.
>

Which of these would be preferable to have:
1. "One common method for provisioning" for all possible scenarios and
access technologies, with no requirements on the end host or CPE, resulting
in a fair number of users with no connectivity? (Note: the "one" method
claim is rather dubious given some major differences inherent to access
technologies you are assuming, eg PPP and IPoE, if not factors like DHCP PD
and others)

2. Use the right tool set for each access scenario, each with a slightly
different configuration but one that ensures iuser connectivity?

3. Set a bar on the minimum _CPE_ requirements that will be supported by the
network (ensuring connectivity) within the given scenarios, along with
potentially having a single configuration/provisioning method? An example of
this would be requiring a routed CPE and/or DHCPv6 support on the CPE/host
(which is what some operators have already done). It might be stating a
truism, but the presence of such a CPE will still allow non-DHCPv6 capable
v6 devices within a user's home to get connected...

I may be not running a network, but the goal of optimizing the amount of
provisioning done by the operator alongside supporting all possible user
access scenarios, all coming at the cost of leaving a good number of such
users with no (or broken) v6 connectivity sounds like a particularly unwise
trade-off and one that should be avoided (which applies to the proposed
approach).

Regards,
Woj.

---

From: "t.petch" <[email-masked]>
Date: Fri, 10 Sep 2010 18:06:07 +0200

----- Original Message -----
From: "Christopher Morrow" <[email-masked]>
To: "Mikael Abrahamsson" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 09, 2010 4:17 PM
> are done as they are in real networks supporting many millions of
I don't buy the line that the IETF has insufficient representation from
operators but I think that your comment on business reasons is
spot on.  The IETF is about engineering and sometimes, hopefully
often, that will provide a solution.  But there is always the alternative
of a business solution which may override engineering, and that is something
that the IETF should stay away from; it lacks the skills in that field.
There has been a lot of business/economics in places such as the RRG
and what I see is the IETF (or IRTF) lacks the skills ever to achieve rough
consensus in that area.

So the onus is on operators to turn their good business reasons into
engineering problems, eg as a requirements RFC, that the IETF will then solve.

Tom Petch

---

From: Doug Barton <[email-masked]>
Date: Fri, 10 Sep 2010 11:46:55 -0700

On 9/10/2010 7:13 AM, Wojciech Dec wrote:
> 3. Set a bar on the minimum _CPE_ requirements that will be supported by
> the network (ensuring connectivity) within the given scenarios, along
> with potentially having a single configuration/provisioning method? An
> example of this would be requiring a routed CPE and/or DHCPv6 support on
> the CPE/host (which is what some operators have already done). It might
> be stating a truism, but the presence of such a CPE will still allow
> non-DHCPv6 capable v6 devices within a user's home to get connected...

Yes, that is the direction I'd go if it were me. And I think you're 
saying this already, but just to be clear if the CPE were able to 
receive its prefix via whatever method (such as DHCP) then pass out RAs 
on the lan side then any host capable of IPv6 would be able to connect 
transparently.

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Fri, 10 Sep 2010 12:04:05 -0700

On 9/10/2010 5:59 AM, Jari Arkko wrote:
> configuration model was intended by the original designers as the
> right one, and so on. I would suggest that while that's interesting,
> it may be secondary to what we are discussing here.

But it's not. My main operational experience, as well as my main IETF 
experience as a participant has been in the DNS. We DNS folk have a long 
history of "Let's find a way to make new stuff work with legacy systems" 
that has led us to the giant mess we're in now. (Unfortunately) it's 
still early days in the history of deployment of IPv6. We _really_ want 
to get this right NOW. Adding more kludges so that we can "Just get it 
deployed" is actually going to make life (and future deployment) harder 
down the road, not easier.

> doesn't help him if some design is the "right" one or matches with
> our *desires* of what hosts and other devices should be doing or
> implementing. The primary concern should be that we have something
> that works.

Wrong wrong wrong wrong wrong. Sorry, but maybe if I say it enough times 
in this post I'll stop having to say it over and over again in 
subsequent posts. I know I'm talking out of both sides of my face here, 
since I'm usually the one who is complaining about the IETF not 
listening to the operators (especially in IPv6) but this is one case 
where the operator is just plain wrong, and what they want to add to the 
specification is a not only a bad idea, it's a dangerous one.

> In particular, we need to worry about what random hosts
> do in these networks, as we cannot dictate what devices will exist in
> people's homes. And we cannot upgrade or change existing
> implementations. This applies both to the problem that started this
> discussion, i.e., hosts giving up on sending RSes but also to their
> support of DHCPv6. As an example, while DHCPv6 is available on Linux,
> none of the IPv6 Linux devices that in my network have come with
> DHCPv6 on by default. (You can of course ask me to change my configs,
> but asking my mother to do the same may not be feasible.)

Your mother runs linux? Cool!

> are in control of their own networks, they probably want to keep
> their underlying L2 network architecture as it is, despite
> introduction of IPv6 or other new features.

Two responses. If we can't expect the hosts to be changed in order for 
this to work, how do we expect them to send clever new RS messages even 
if the draft is adopted (or perhaps I'm misunderstanding something)? And 
I don't know if it's common in other countries or not, but every 
broadband account I've ever signed up for in the US has come with a 
dis[kc] of special software that I "had to install" to make my system 
able to access the intartubez. Now back in the 90's when these things 
came on floppy disks there often was some sort of mandatory sign-in 
software that I couldn't get on line without. Since I was dual-booting 
FreeBSD at the time, and the software was only available for windows, I 
had to figure out a solution for myself because my OS was not supported.

Nowadays these things come on CD, and I've long since learned NOT to 
install them because they are overwhelmingly likely to do Bad 
Things(TM). But it does make one think that there may be a solution to 
the "Random host doesn't do DHCPv6, and/or doesn't do it by default" 
problem; even if one doesn't like Woj's CPE-related solution (which I've 
already said I do think is the right answer).

Doug

--

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Sep 2010 08:24:35 +1200

> That would actually materially surprise me, as the same systems are delivered to both markets. What I observe is that Windows 7, Macintosh, and *nix all default to some variant of SLAAC, and some o…

That's fair comment, but observe that (e.g.) Windows seems to come in different
editions aimed at home, small office and enterprise environments, and that those
editions tend to have different defaults. And certainly in enterprises, the defaults
may be changed yet again in the o/s image distributed to users.

   Brian

---

From: Ralph Droms <[email-masked]>
Date: Fri, 10 Sep 2010 16:23:30 +0200

I agree that connecting non-DHCPv6 hosts directly to the proposed architecture is problematic.  It's good to ask about alternatives to solve the problem, to understand how big the problem is and to understand whether the alternatives are effective solutions.

I disagree that it's always better to provide options; sometimes, depending on the amount of work required to generate the options and the size of the problem being solved, it may be better to ask that the deployment conform to the existing options rather than defining new options.  In this particular case, we need to balance the work required to define the RS-tagging option - allowing for future work which will likely be required to complete the work based on our experience with the similar extensions to DHCP - against suggesting that deployments adapt to the existing mechanisms which are designed to support the underlying network architecture (as I understand it).

I understand that you are looking to accommodate subscribers that have devices that are not DHCPv6-capable and that are directly connected to the SP network.  How many of those devices will actually be able to move to IPv6 and do we want to expend the effort in design and implementation to accommodate those devices, when there is the alternative of connecting those devices through a home gateway?

- Ralph

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 10 Sep 2010 14:39:17 -0700

Hi Suresh,

Suresh Krishnan wrote:
> >> RAs/SLAAC work very well when RAs can be multicast to *all* nodes on
> >> a link, and *all* nodes receive exactly the same information about
> > Right, what we essentially have here (and what has been referred to
> > as "N:1 VLAN allocation model") is a point-to-multipoint link model
> > that constitutes a broadcast domain but where there is a desire to
> > advertize different prefixes to different endpoints (CPEs at the
> > multipoint end.)
> >
> > The 16ng WG has managed to do so something similar over the IEEE
> > 802.16 link layer that is documented in RFC 5121. In 16ng however, from
> > the perspective of the edge router, each of branch of the point-to-
> > multipoint 802.16 link layer appears as a distinct link to the IP layer,
> > thanks to the use of distinct, per-endpoint, IEEE 802.16 connection IDs
> > and tunneling between the edge router and the aggregation point.
> > Because there is a different link between the edge router and the
> > endpoints, the edge router can multicast unsolicited RAs containing a
> > per-endpoint prefix on each of the links.
> >
> > In BBF this cannot be done because there is no tunneling between the
> > access node and the edge router, and thus the edge routers sees only
> > one link.
> >
> > Maybe it is time to write an "Issues with Per-Endpoint Subnet Link
> > Model on Point-to-Multipoint Links" that would explains the caveats
> > that exists, ala RFC 4903.
> 
> with this kind of usage will be invaluable. I am looking forward to
> read and contribute.

I will give it a try. I have spent a fair amount of time working on this in the early days of the NETLMM WG while trying to support shared links where each mobile node configure an address in a different prefix. 

--julien

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Sep 2010 09:54:38 +0930

On Fri, 10 Sep 2010 07:34:42 +0200 (CEST)

> protocols designed in the IETF hasn't had that part as a design criteria.

How would you solve the problem? If you give end-nodes the ability to
build packets, you're giving them the ability to choose the source
address. The only options are to verify the source address externally
e.g. SeND, SAVI or quarantine them individually on point-to-point
links and use RPF validation, or somewhat radically change the protocol
such that source addresses of packets are only set by upstream devices
(and for that to work you'd need point-to-point links with the upstream
device anyway). The latter option would take away the peer-to-peer
nature of the Internet Protocols.

If you truly don't trust the end-nodes at all to set their source
address correctly, then quarantining them on individual point-to-point
links would seem to me to be the only option that still allows other
people in other environments to continue to trust end-nodes setting the
source address.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 10 Sep 2010 23:15:35 -0400

Hi Doug,
   Just clarifying one technical point that you raised.

> if the draft is adopted (or perhaps I'm misunderstanding something)? And 

The hosts do not get changed at all. They send standard RS messages (as 
defined in RFC4861). The "clever new" RS messages you refer to are 
actually not RS messages at all. They are plain old RS messages tunneled 
in another IPv6 datagram between the access node and the edge router.

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Sep 2010 16:20:37 +1200

> such that source addresses of packets are only set by upstream devices

Those devices exist today and are called NATs.

This way lies madness. We aren't designing the telephone system.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 Sep 2010 12:26:30 +0900

On Sep 11, 2010, at 1:06 AM, t.petch wrote:
> So the onus is on operators to turn their good business reasons into engineering problems, eg as a requirements RFC, that the IETF will then solve.

Thanks. I gather the operators have gotten a lot of bashing from IETF participants in the past; I'm sorry for that, and apologize if I was involved. What I see in the present, and specifically in this thread and similar threads in v6ops and other places, is the reverse: operator bashing of the IETF.

Vendors, generally speaking, are not interested in building castles in the sky. They are interested in solving customer problems, which is to say creating solutions - products and features - that operators are interested in buying. Operators are interested in how the solutions work, but in general are far more interested in how they can be used to solve the business problems you speak of. If there is a single reason that vendors are more obvious in the IETF (which I will argue is the case, not that they are the only ones present), it is that the IETF is about building solutions, and therefore very much the domain of people that make products and features, just as the *NOGs are very much the domain of people that use those solutions.

To that end, the IETF has since the beginning been a place where customer and vendor meet and write - academic research, vendors, and enterprise, access, and transit network operators. I can point to RFC and RFC that I have written and that others have written that have combined operational, vendor, and researcher authorship. When any person in any of those camps shows disrespect toward another, he says more about himself than about the party or camp he is disrespecting.

If I may make a humble request - could we get back to work, please?

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Sep 2010 22:00:04 -0700

>> engineering problems, eg as a requirements RFC, that the IETF will

no.  it is the duty of operators to turn their business plans into
operational practice, deliver packets, and charge the customers.

and it is for ietf to get running code and protocol specs.

and it is not the duty of ietf to create or constrain operators'
business plans or delivery.

randy

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 Sep 2010 14:27:40 +0900

> business plans or delivery.

It certainly *is* the role of the IETF to develop tools the the operators can use to do that. I don't know how we accomplish that without talking with one another. Could we end the pissing match?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 Sep 2010 08:06:39 +0200 (CEST)

> How would you solve the problem? If you give end-nodes the ability to

Exactly the way it has been done for IPv4 with the mechanisms I've given 
examples of before. L2 devices look at DHCPv6 etc and then enforce policy 
accordingly. The thing here is that these mechanisms should have been 
designed alongside IPv6 and all the "core" protocols in IPv6 should have 
been designed with this in mind, making it easy and cheap for L2 devices 
to find the traffic they need to look at.

Now whatever L2 devices need to look at is what is available, and some 
isn't that easy to find and it might have to look at multiple things, some 
of which is of no interest to it.

> people in other environments to continue to trust end-nodes setting the 

*sigh* Taking the easy way out again. Point to point links are expensive.

Equipment doing q-in-q and/or PPPoE termination carry a hefty premium over 
the ones who don't, especially if they need to handle thousands of 
customers (ie thousands of interfaces). Compare this to a Cisco 3550 which 
can route thousands of customers in a few subnets if needed.

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 Sep 2010 15:12:42 +0900

On Sep 11, 2010, at 3:06 PM, Mikael Abrahamsson wrote:

> Exactly the way it has been done for IPv4 with the mechanisms I've given examples of before. L2 devices look at DHCPv6 etc and then enforce policy accordingly. The thing here is that these mechanisms should have been designed alongside IPv6 and all the "core" protocols in IPv6 should have been designed with this in mind, making it easy and cheap for L2 devices to find the traffic they need to look at.

http://datatracker.ietf.org/wg/savi/

For the record, this is relatively recent for IPv4 as well.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 Sep 2010 08:23:08 +0200 (CEST)

> If I may make a humble request - could we get back to work, please?

Good post.

I guess I've been part of the bashing. It's a fine line between saying 
that things haven't been done to solve current problems and there is a lot 
of improvement to do, and going to far and it turns into bashing. Sorry.

The reason why I get so frustrated is that here I'm sitting with a 
deployment model with millions of customers, in a country that is at the 
top of the broadband penetration and bw list, and the feeling I'm getting 
from people here is not even an acceptance that this is a valid deployment 
model. This deployment model is 10 years old, I did my first such 
installation in 1999. A lot of development went into this in 2000-2002 to 
make it secure with DHCP inspection, STP source guard, the whole 
IPv4/ethernet suite. It's been very successful in these markets with the 
highest per-customer speeds of any deployment model I'm aware of and at a 
end user price of 10/10 ETTH as low as USD10 per month in large 
deployments.

"You're doing it wrong, go away".

Doing PPPoE to customers with 100/100 megabit/s ETTH accesses is just not 
economically feasable. First of all there aren't CPEs that are fast enough 
and the tunnel termination router gets really expensive because instead of 
a fairly cheap L3 switch and "always on" (DHCP only), you have to 
complicate things a lot more for both customers and yourself.

So here we are, 10 years after this was done for IPv4 and it hasn't been 
done for IPv6, and that's why IPv6 is undeployable in these networks, and 
it seems quite a lot of people don't even think this is a problem.

Sorry for being frustrated and saying things I perhaps shouldn't, but I 
hope the above might explain a few things.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 11 Sep 2010 11:27:37 +0300

Doug,

> But it's not. ... We _really_ want to get this right NOW. Adding more 
> kludges so that we can "Just get it deployed" is actually going to 
> make life (and future deployment) harder down the road, not easier.

Agreed so far.

> Wrong wrong wrong wrong wrong. Sorry, but maybe if I say it enough 
> times in this post I'll stop having to say it over and over again in 
> subsequent posts. I know I'm talking out of both sides of my face 
> here, since I'm usually the one who is complaining about the IETF not 
> where the operator is just plain wrong, and what they want to add to 
> the specification is a not only a bad idea, it's a dangerous one.

Maybe there's a misunderstanding somewhere, but I did not argue in favor 
of any particular solution or architecture. I do get the point that we 
have to look at the architecture, the need for this model of deployment 
and make some hard decisions about what's reasonable.

But if your argument is that we should ignore real life problems, then, 
sorry, I'm obviously going to disagree. My point is that no matter what 
we are doing (Suresh's option, DHCPv6, something else) we should try to 
understand the practical implications for people that are using these 
things. Its not enough that all the specs are aligned or that in theory 
you can the network to work. It really has to work by default on all 
devices, given that we are talking about consumers. As an example, it is 
IMHO not enough that software is available on a given platform, if it is 
not turned on by default then for all practical purposes its not there. 
If you look at it this way, then in my experience at least the devices 
that cannot do DHCPv6 are not a small minority that can be ignored as a 
corner case.

> this to work, how do we expect them to send clever new RS messages 
> even if the draft is adopted (or perhaps I'm misunderstanding something)?

That's the problem. Or one of the problems in one particular solution.

> And I don't know if it's common in other countries or not, but every 
> software that I couldn't get on line without.

In my experience that is not so common these days any more. YMMV.

> Since I was dual-booting FreeBSD at the time, and the software was 
> only available for windows, I had to figure out a solution for myself 
> because my OS was not supported.
>
> problem; even if one doesn't like Woj's CPE-related solution (which 
> I've already said I do think is the right answer).

Not really, IMO. First of all, if we are talking about a bridged, not 
routed home network then there are likely to be multiple computers, 
several appliances and so on that are all visible to the service 
provider and that all need an address. There's no way the service 
provider can give you updates for all of these.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Sep 2010 08:35:54 +1200

Mikael,

> The reason why I get so frustrated is that here I'm sitting with a deployment model with millions of customers, in a country that is at the top of the broadband penetration and bw list, and the feeling I'm getting from people here is not even an acceptance that this is a valid deployment model.

Is there a writeup of the model as a whole? If not, it would be immensely
useful (and maybe this discussion belongs on v6ops or opsawg).

Regards
   Brian Carpenter

On 2010-09-11 18:23, Mikael Abrahamsson wrote:
> that things haven't been done to solve current problems and there is a
> lot of improvement to do, and going to far and it turns into bashing.
> Sorry.
> 
> top of the broadband penetration and bw list, and the feeling I'm
> getting from people here is not even an acceptance that this is a valid
> deployment model. This deployment model is 10 years old, I did my first
> such installation in 1999. A lot of development went into this in
> 2000-2002 to make it secure with DHCP inspection, STP source guard, the
> whole IPv4/ethernet suite. It's been very successful in these markets
> with the highest per-customer speeds of any deployment model I'm aware
> of and at a end user price of 10/10 ETTH as low as USD10 per month in
> large deployments.
> 
> Doing PPPoE to customers with 100/100 megabit/s ETTH accesses is just
> not economically feasable. First of all there aren't CPEs that are fast
> enough and the tunnel termination router gets really expensive because
> instead of a fairly cheap L3 switch and "always on" (DHCP only), you
> have to complicate things a lot more for both customers and yourself.
> 
> done for IPv6, and that's why IPv6 is undeployable in these networks,
> and it seems quite a lot of people don't even think this is a problem.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 Sep 2010 23:14:41 +0200 (CEST)

On Sun, 12 Sep 2010, Brian E Carpenter wrote:

> Is there a writeup of the model as a whole? If not, it would be 
> immensely useful (and maybe this discussion belongs on v6ops or opsawg).

I've asked Fred if he knows of a write-up/whitepaper, Cisco has customers 
with extensive deployments of this.

Looking a bit, I found 
<http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/chap5.html>. 
The interesting parts are around "Port Security Considerations", "DHCP 
protection", "ARP spoofing protection", and the likes.

But as Fred also mentioned, SAVI WG is working in specifically this area 
<https://datatracker.ietf.org/wg/savi/charter/>

There also is no "one model" for this, there are multiple variants. Some 
rely on MAC 1:1 re-write to do a lot of the L2 protection needed (Ericsson 
Ethernet DSLAMs and ETTH nodes do this for instance). Some let end users 
choose MAC addresses and rely on MAC uniqueness, and try to do the rest by 
inspecting policy traffic as it flows along and implement different 
filters.

Also regarding this "belonging" on other lists. I'm not sure. Deployment 
models need to be understood by people proposing and critiquing work being 
done in all related WGs. Having people dismiss other peoples 
opinions/ideas because they don't understand a deployment model and 
rationale behind why someone is proposing something is causing 
unneccessary friction on the lists. I've multiple times been thinking "why 
the hell am I doing this, my forehead is bloody enough as it is" and 
throwing my hands up and leaving, but I try to dig in and continue.

I hope others do the same thing, we need to get IPv6 deployable.

---

From: Mark Smith <[email-masked]>
Date: Sun, 12 Sep 2010 08:33:27 +0930

On Sat, 11 Sep 2010 08:06:39 +0200 (CEST)
Mikael Abrahamsson <[email-masked]> wrote:

> examples of before.

Your criticisms seemed to be architectural ones - that the IETF hadn't
designed a protocol that addressed these issues. So my question was how
would you solve it (architecturally)?

Layer 2 devices inspecting traffic isn't architecturally acceptable
because it's a layer violation, address rewriting or insertion isn't
because it takes away the end-node's peer status at the network layer,
which creates all the consequences we know of from v4 NAT. I don't
disagree about the costs of using point-to-point links (virtual or
otherwise) to quarantine end-nodes, however increased security usually
involves increased cost, so it is a security/cost tradeoff. The
advantage of point-to-point/quarantine model over other options is
that it both fits and maintains the existing architecture.

> L2 devices look at DHCPv6 etc and then enforce policy

---

From: [email-masked]
Date: Sun, 12 Sep 2010 05:22:18 +0200 (CEST)

> because it's a layer violation,

L2 inspection of (IPv4) L3 traffic is a heavily used feature in some
environments, and is promoted by for instance Cisco as one part of
"Access Security Best Practices" (see the reference Mikael Abrahamsson
provided).

The same functionality is of course needed for IPv6. If people have a
hard time accepting that I'd say they're badly out of touch with the
real networking world.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Sep 2010 17:28:54 +1200

> hard time accepting that I'd say they're badly out of touch with the

The reason layer violation is considered architecturally wrong is
that it means that layer n devices become an obstacle to deploying
new layer n+1 protocols, or vice versa.

So, indeed, those who market layer 2 solutions relying on layer
violation will have to update their products when a new layer 3 arrives.

That's a statement of fact, not an emotional reaction, BTW.

     Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 12 Sep 2010 07:29:10 +0200 (CEST)

On Sun, 12 Sep 2010, Mark Smith wrote:

> So my question was how would you solve it (architecturally)?
>

+1 on what Steinar Haug wrote.

Serious disconnect between map and reality here, Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 12 Sep 2010 07:30:44 +0200 (CEST)

> violation will have to update their products when a new layer 3 arrives.

That is perfectly understandable and that's not something anyone is 
opposing as far as I can see.

---

From: Mark Smith <[email-masked]>
Date: Sun, 12 Sep 2010 19:14:40 +0930

On Sun, 12 Sep 2010 07:29:10 +0200 (CEST)

> Serious disconnect between map and reality here, Mark.

If you think that, then I don't think you've read my emails
properly.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 12 Sep 2010 11:58:45 +0200 (CEST)

> If you think that, then I don't think you've read my emails

... or there is a serious disconnect between your reality and my reality.

By saying that L2 devices doing L3 inspection is a layer violation and 
isn't acceptable, you've dismissed the way millions of people are 
connected to the internet as... er, I don't know. Not acceptable and 
wrong.

If I have misunderstood your posting, please enlighten me.

---

From: [email-masked]
Date: Sun, 12 Sep 2010 12:57:48 +0200 (CEST)

> connected to the internet as... er, I don't know. Not acceptable and 

Maybe we're disagreeing on the meaning of the word "acceptable".

I think most of us can agree that L2 devices doing L3 inspection is a
layer violation.

What a lot of us can *not* agree to is simply dismissing such a feature
*just because it is a layer violation*.

IPv6 in general is purely an added cost for the providers so far - no
fresh revenue expected in the near future. That means we cannot do large
scale changes of our current architecture. As a consequenc of this, we
need largely the same functionality available for IPv6 as we have for
IPv4 - *even if that fucntionality happens to be a layer violation*.

We need IPv6 to be "business as usual" as much as possible. A feature
like L2 devices doing L3 inspection is, as far as I can see, a mostly
software thing: Hardware filter to intercept the traffic and route it
to the CPU, probably hardware rate limiting, software doing the actual
inspection. Thus is should be possible to a similar thing for IPv6.

---

From: Mark Smith <[email-masked]>
Date: Sun, 12 Sep 2010 20:31:47 +0930

On Sun, 12 Sep 2010 11:58:45 +0200 (CEST)
Mikael Abrahamsson <[email-masked]> wrote:

> isn't acceptable,

What I said was, and I'll highlight the key word,

"Layer 2 devices inspecting traffic isn't *architecturally* acceptable
because it's a layer violation"

The best place to fix IPv6 issues in in IPv6. If you fix try to them at
the layer below, you end up with layer 2 specific solutions, and will
need one for every existing and new layer 2 that comes along. If,
however, you solve them in IPv6, then you have a single solution that
is applicable to every layer 2, both current and future ones.

It comes down to solving the problem once and for all, rather than
readdressing it each and every time you encounter it in a
slightly different scenario.

One of the ultimate consequence of this layer violation is that
perfectly capable layer 2 devices are going to have to be replaced to
support IPv6 if people want to obtain IPv4/IPv6 feature parity. On the
scale IPv6 is going to be deployed, that is an awfully large amount of
perfectly functioning layer 2 equipment that is going to be discarded.

So I accept layer violations to perform some of these functions, but I
think it'd be preferable if they could be avoided.

> you've dismissed the way millions of people are

---

From: Mark Smith <[email-masked]>
Date: Sun, 12 Sep 2010 20:43:10 +0930

> inspection. Thus is should be possible to a similar thing for IPv6.

Unfortunately I know of an instance where the vendor of DSLAM equipment
is saying the hardware doesn't have the resources to do these layer 3
inspections for IPv6. So 10s of 1000s of DSLAMs would need to be
replaced. Unfortunately, this means the market is going to stay with
using PPPoE/PPP despite the overheads.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 12 Sep 2010 13:14:44 +0200 (CEST)

> think it'd be preferable if they could be avoided.

Of course it is preferrable if they can be avoided.

Problem is that the method you're suggesting to solve this with, is not 
economically viable in my world.

Now what?

---

From: Fred Baker <[email-masked]>
Date: Sun, 12 Sep 2010 22:01:19 -0700

On Sep 12, 2010, at 4:01 AM, Mark Smith wrote:

> The best place to fix IPv6 issues in in IPv6. 

well, yes, but...

let me give you one example.

A few years back, in 2002 I believe, Cisco worked out that BCP 38 was pretty important to a subset of its customers that wanted it to apply to people on the same subnet. In short, IPv4 customers wanted to be prevented from classes of attacks that involved spoofing a source address, and having eliminated those attacks, wanted ISPs to be able to track other attacks to their sources. This applied to, among others, access ISPs. So we came up with a feature (which we patented) called IP Source Guard. It snoops DHCP, notes the IPv4 address allocated to a (MAC address on a) port, and sets the Catalyst 6K port filters to drop traffic from that port (and MAC Address) that doesn't have that source address.

The existence of the port filter tells you that network administrators had already been installing other filters, such as looking at the transport layer port, for other reasons.

Other companies copied the feature. Per a note earlier in this thread, it is something that at least one ISP considers essential to making IPv4 deployable in access networks.

SAVI is working on the same feature for IPv6. The technologies under consideration include DHCP snooping, SLAAC snooping, and SEND snooping. Note that the IPv4 feature was never standardized.

I can do that in other ways. I could imagine, for example, every host and router on a LAN maintaining a set of registered neighbors and only being willing to talk with neighbors that were registered. That model is under discussion in 6LowPAN. To do that, I need to change every host implementation and every router implementation, and I give up something - an attacker still costs the switched network bandwidth when he sends a message, as it has to be received. If I allow the layer violation, the host costs itself the bandwidth on its own port, but the switch would never send it on.

In general, I would agree that the place to fix an issue is in the core protocol for the issue. But for an operational network, the choice of protocol is far less important than the characteristics of the solution they are trying to achieve. Sometimes, holding one's nose and crossing the layer boundaries is the right choice.

---

From: <[email-masked]>
Date: Mon, 13 Sep 2010 08:49:35 +0200

Hi Woj,
 
thx for your comments. I nearly forgot that an ISP has to offer its customers a good service, thx for reminding me ;-).
I'm just inserting as an answer a sentence, I found in an email posted by Tom Petch on this mailing list in another context:
 
Tom Petch wrote on Fr 10.09.2010 18:06:
".... So the onus is on operators to turn their good business reasons into engineering problems, eg as a requirements RFC, that the IETF will then solve. "
 
I know the problem and look for a solution. Hence it would be very helpful to discuss solutions (and I-D krishnan-rs-mark is at least an approach to that) and not just holding long tirades how bad the problem is. 
 
Just my 0.02 €.
    Olaf

  _____  

Von: Wojciech Dec [mailto:[email-masked]] 
Gesendet: Freitag, 10. September 2010 16:14
An: Bonneß, Olaf
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: New version available

Which of these would be preferable to have:
1. "One common method for provisioning" for all possible scenarios and access technologies, with no requirements on the end host or CPE, resulting in a fair number of users with no connectivity? (Note: the "one" method claim is rather dubious given some major differences inherent to access technologies you are assuming, eg PPP and IPoE, if not factors like DHCP PD and others) 

2. Use the right tool set for each access scenario, each with a slightly different configuration but one that ensures iuser connectivity?

3. Set a bar on the minimum _CPE_ requirements that will be supported by the network (ensuring connectivity) within the given scenarios, along with potentially having a single configuration/provisioning method? An example of this would be requiring a routed CPE and/or DHCPv6 support on the CPE/host (which is what some operators have already done). It might be stating a truism, but the presence of such a CPE will still allow non-DHCPv6 capable v6 devices within a user's home to get connected...

I may be not running a network, but the goal of optimizing the amount of provisioning done by the operator alongside supporting all possible user access scenarios, all coming at the cost of leaving a good number of such users with no (or broken) v6 connectivity sounds like a particularly unwise trade-off and one that should be avoided (which applies to the proposed approach).

Regards,
Woj.

Ciao
       Olaf

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Sep 2010 09:16:15 +0200

Olaf,

> I know the problem and look for a solution. Hence it would be very helpful to discuss solutions (and I-D krishnan-rs-mark is at least an approach to that) and not just holding long tirades how bad…

so which solutions do we have:

1) only support DHCP on the BBF link-layer in the N:1 VLAN case.
     this will affect some legacy host implementations in the case where the customer has a bridged connection to the access network.
     how big a problem is this? considering that this is the route DOCSIS has gone with DOCSIS 3.0...
     
2) RS mark.
     it appears consensus is that this will not work.

3) tunneling and tagging traffic between AN and BNG.

4) move L3 border to AN

5) change SLAAC

with regards to the requirement that the solution should support existing host implementations that do not support DHCPv6.

let us say we have 5 classes of host implementations:

1) IPv4 only and those which will never be upgraded with IPv6 support
2) partly broken IPv6 support and without DHCPv6
3) partly broken IPv6 support with DHCPv6
4) full IPv6 support without DHCPv6
5) full IPv6 support with DHCPv6

by partly broken I mean lacking dual stack / IPv4/IPv6 multihoming support. i.e happy eyeballs or having other serious short comings. I do not want to enable IPv6 on hosts implementations that e.g have 75 second timeout to switch from IPv6 to IPv4 (well known fruit vendor).

we don't care about 1. we do _not_ want to deliver IPv6 service to 2 + 3. so the problematic one is 4.
does anyone know of any class 4 IPv6 implementation?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 13 Sep 2010 09:22:16 +0200 (CEST)

On Mon, 13 Sep 2010, Ole Troan wrote:

> we don't care about 1. we do _not_ want to deliver IPv6 service to 2 + 
> 3. so the problematic one is 4. does anyone know of any class 4 IPv6 
> implementation?

I'd imagine cany class 4 IPv6 devices will quickly be pushed out of the 
market anyway. I consider DHCPv6 support as an essential component for any 
device connecting to the Internet, and I wouldn't even call it "Full" if 
DHCPv6 support is lacking.

---

From: <[email-masked]>
Date: Mon, 13 Sep 2010 10:33:25 +0200

Hi Ole,

thx for your analysis of the problem space.
Please find my comments in line.

Ciao
	Olaf

> -----Ursprüngliche Nachricht-----
> Von: Ole Troan [mailto:[email-masked]] Im Auftrag 
> von Ole Troan
> Gesendet: Montag, 13. September 2010 09:16
> An: Bonneß, Olaf
> Cc: [email-masked]; [email-masked]
> Betreff: Re: AW: New version available
> 
> Olaf,
--------------
...
--------------
>      this will affect some legacy host implementations in the 
> case where the customer has a bridged connection to the 
> access network.

OBo: Agree that DHCPv6 could be used to provide address/prefix informations also in N:1 VLAN scenario and you mentioned as well the affects to legacy host implementations. I'm not speaking about DOCSIS networks.
   
>      it appears consensus is that this will not work.

OBo: Hmm, I'm still not convinced that this will not work. May be I'm outside the consensus here :).

> 3) tunneling and tagging traffic between AN and BNG.

OBo: Possible.
 
> 4) move L3 border to AN

OBo: Theoretically possible as well. But this means a heavy restructuring of the whole access network infrastructure and the provisioning model etc.

> 5) change SLAAC

OBo: Extending SLAAC could provide a solution but it means also scratching the fundaments of IPv6. 

> with regards to the requirement that the solution should 
> support existing host implementations that do not support DHCPv6.
> 
> by partly broken I mean lacking dual stack / IPv4/IPv6 
> multihoming support. i.e happy eyeballs or having other 
> serious short comings. I do not want to enable IPv6 on hosts 
> implementations that e.g have 75 second timeout to switch 
> from IPv6 to IPv4 (well known fruit vendor).

OBo: Hmm not sure if I understood what "partly broken" means. Have to think about once more what you are trying to say here.

> we don't care about 1. we do _not_ want to deliver IPv6 
> service to 2 + 3. so the problematic one is 4.

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 13 Sep 2010 10:59:44 +0200

On 13 September 2010 08:49, <[email-masked]> wrote:

>  Hi Woj,
>
> thx for your comments. I nearly forgot that an ISP has to offer its
> customers a good service, thx for reminding me ;-).
> I'm just inserting as an answer a sentence, I found in an email posted by
> Tom Petch on this mailing list in another context:
>
> ".... So the onus is on operators to turn their good business reasons into
> engineering problems, eg as a requirements RFC, that the IETF will then
> solve. "
>
> I know the problem and look for a solution. Hence it would be very helpful
> to discuss solutions (and I-D krishnan-rs-mark is at least an approach to
> that) and not just holding long tirades how bad the problem is.
>

Quite the contrary. My earlier mail gave a number of valid options. The
approach espoused by the current rs-mark, which you appear to support,
requires a modification of the existing ICMPv6 spec as well as host
implementations. Is this the type of solution you are after? How does that
factor into your business reasons?

Thanks,
Woj.

Thanks,
Woj.

>
> Just my 0.02 €.
>     Olaf
>
>
>  ------------------------------
>  *Von:* Wojciech Dec [mailto:[email-masked]]
> *Gesendet:* Freitag, 10. September 2010 16:14
> *An:* Bonneß, Olaf
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> *Betreff:* Re: New version available
>
>
>
>> And since SLAAC is one of the valid mechanisms for doing that (according
>> to WT-187) I'm interested to learn if/how that can also work for N:1 VLANs.
>> And I-D krishnan-6man-rs-mark is describing such an approach. Thats why I'm
>> also interested in that I-D.
>>
>
> the network (ensuring connectivity) within the given scenarios, along with

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Sep 2010 11:20:00 +0200

Olaf,

> OBo: Hmm not sure if I understood what "partly broken" means. Have to think about once more what you are trying to say here.

sorry for not giving more references. basically I'm thinking of a slightly more generalized version of the problem described here:
http://tools.ietf.org/html/draft-wing-http-new-tech-01

to cite an example. the host implementation that I am using, has a 75 second timeout from trying an IPv6 connection to trying an IPv4 connection. and while it does A and AAAA lookups in parallel it picks the first reply and that leads to indeterministic behaviour.

cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 13 Sep 2010 11:42:49 +0200

Hi Woj,
 
thx for your answer. I think, that you 've misunderstood / misinterpreted my words. I'm sure that you know very well that a service provider wants to change as little as possible and that he can not influence / modify all host implementations on customer site. 
Regarding I-D krishnan-rs-mark I've simply the feeling that it might have the potential to solve the sketched problem.  Perhaps not in the current version (see the long list of discussion on this mail exploder), nevertheless lets wait for  the next round of improvement ;-).
Ciao
    Olaf

Quite the contrary. My earlier mail gave a number of valid options. The approach espoused by the current rs-mark, which you appear to support, requires a modification of the existing ICMPv6 spec as well as host implementations. Is this the type of solution you are after? How does that factor into your business reasons?

Thanks,
Woj.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Sep 2010 10:17:49 -0400

Hi Ole,

> does anyone know of any class 4 IPv6 implementation?

Windows XP.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Sep 2010 10:23:24 -0400

Hi Ole,

> to cite an example. the host implementation that I am using, has a 75 second timeout from trying an IPv6 connection to trying an IPv4 connection. and while it does A and AAAA lookups in parallel it…

While this is a valid problem, this has nothing to do with the issue 
that we are discussing. This can be fixed in the following ways without 
requiring protocol changes.

* Host based IPv6 tunneling mechanisms with 
questionable/intermittent/broken reachability should not be turned on.
* ISPs who do not have upstream IPv6 connectivity towards the content 
providers should probably not enable IPv6 for their customers.

Cheers
Suresh

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Sep 2010 16:31:57 +0200

Suresh,

>> does anyone know of any class 4 IPv6 implementation?

does XP come with IPv6 enabled by default? if not I would classify it with Win95... i.e. don't care.
with IPv6 enabled, does it even give me happy eyeballs? most likely a class 2 stack, which would need an upgrade anyway.

cheers,
Ole

---

From: <[email-masked]>
Date: Tue, 14 Sep 2010 10:40:17 -0400

The whole lack of IPv6 transport in XP for DNS kinda fails the 'full IPv6 support without DHCPv6' classifier for me. 

Jason

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ole Troan
> Sent: Tuesday, September 14, 2010 10:32 AM
> To: Suresh Krishnan
> Cc: [email-masked]; [email-masked]
> Subject: Re: AW: New version available
> 
> Suresh,
> 
> does XP come with IPv6 enabled by default? if not I would 
> classify it with Win95... i.e. don't care.
> with IPv6 enabled, does it even give me happy eyeballs? most 
> likely a class 2 stack, which would need an upgrade anyway.
> 
> cheers,
> Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Sep 2010 16:41:01 +0200

Sursh,

> While this is a valid problem, this has nothing to do with the issue that we are discussing.

I think it does.
if your argument is that the access layer has to support SLAAC because of the high number of "legacy" hosts, then my argument to refute that is that you have to upgrade those hosts anyway, otherwise you will have users with blood shot eyes. ;-)

> This can be fixed in the following ways without requiring protocol changes.
> 
> * Host based IPv6 tunneling mechanisms with questionable/intermittent/broken reachability should not be turned on.
> * ISPs who do not have upstream IPv6 connectivity towards the content providers should probably not enable IPv6 for their customers.

that will certainly help the problem, but not solve it. either the IPv4 or the IPv6 path may be broken at a given time, and having an implementation having the user wait 75 seconds is unacceptable. now, if we agree that legacy hosts will have to be upgraded, it does of course not mean that they will also be upgraded with DHCPv6 support, but at least there is an opportunity for that.

cheers,
Ole

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 14 Sep 2010 10:46:19 -0400

XP has limitations but is still usable if IPv6 is enabled.

On 9/14/10 10:40 AM, "Jason Weil" <[email-masked]> wrote:

> The whole lack of IPv6 transport in XP for DNS kinda fails the 'full IPv6
> support without DHCPv6' classifier for me.
> 
> Jason
> 
> 
> 

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

---

From: <[email-masked]>
Date: Tue, 14 Sep 2010 10:50:51 -0400

True. 

Usable in a dual-stack environment.

Not usable IPv6-only.

Jason

> From: John Jason Brzozowski 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 14, 2010 10:46 AM
> To: Weil, Jason (CCI-Atlanta); [email-masked]; Suresh Krishnan

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 14 Sep 2010 11:13:14 -0400

Agreed.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Sep 2010 11:59:48 -0400

Hi Jason,

> Usable in a dual-stack environment.

Absolutely right. The BBF architecture in question is dual-stack.

Thanks
Suresh

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Sep 2010 12:08:53 -0400

> XP has limitations but is still usable if IPv6 is enabled.

on a dual-stack lan, or one with a specific dns-over-v4 crutch for xp

randy

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 14 Sep 2010 21:46:04 -0400

I was referring to dual stack.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Sep 2010 15:02:20 +1200

Mikael,

On 2010-09-12 09:14, Mikael Abrahamsson wrote:
> I've asked Fred if he knows of a write-up/whitepaper, Cisco has
> customers with extensive deployments of this.
> 
> Looking a bit, I found

Thanks for that. Now, what is needed for those techniques to be
fully deployable for IPv6, except work by the vendor(s)? Is there
any work needed on the basic IPv6 standards?

If not, this is exactly the sort of issue that we are starting to discuss
in the newest push in v6ops(@ietf.org) and its v4v6tran sub-discussion.
See draft-lee-v4v6tran-problem, draft-carpenter-v4v6tran-framework,
and several other drafts matching *v4v6tran*.

> <https://datatracker.ietf.org/wg/savi/charter/>

Sure. Are you holding your breath?

> rely on MAC 1:1 re-write to do a lot of the L2 protection needed
> (Ericsson Ethernet DSLAMs and ETTH nodes do this for instance). Some let
> end users choose MAC addresses and rely on MAC uniqueness, and try to do
> the rest by inspecting policy traffic as it flows along and implement
> different filters.
> 
> models need to be understood by people proposing and critiquing work
> being done in all related WGs. Having people dismiss other peoples
> unneccessary friction on the lists. I've multiple times been thinking
> "why the hell am I doing this, my forehead is bloody enough as it is"
> and throwing my hands up and leaving, but I try to dig in and continue.
> 

Yes, and thank you for persisting.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 20 Sep 2010 07:31:05 +0200 (CEST)

> any work needed on the basic IPv6 standards?

Well, I think what would help is to be able to run a DHCPv6 only 
environment without RA/RS, it would also help if one didn't need NS 
either. The whole L2 environment would need a lot less code, it basically 
would only need to be able to filter the above mechanisms, not inspect 
them.

> Sure. Are you holding your breath?

Well, duplicating work is probably a bad idea. They have running code, I 
don't see why people who want to fix this shouldn't join them in their 
effort. Am I missing something?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Sep 2010 10:49:13 +1200

On 2010-09-20 17:31, Mikael Abrahamsson wrote:
> either. The whole L2 environment would need a lot less code, it
> basically would only need to be able to filter the above mechanisms, not
> inspect them.

I think the technical issue there is that ND and RA were designed as a
package, and you certainly can't run without ND.

[Historical note: the ND/RA design was done at a time when all we
had deployed was ARP, because DHCP was not yet mature, and most of us
were still configuring IPv4 hosts manually. ND/RA seemed like an
enormous leap forward.]

> effort. Am I missing something?

I'm just wondering how many years it will be before SAVI is an off-the-shelf
multivendor solution.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Sep 2010 07:41:23 +0200 (CEST)

> package, and you certainly can't run without ND.

Well, the DHCPv6 standard can be changed to hand out information so ND 
isn't needed. This is what I had in mind. This would remove the need for 
the whole RA/ND/RS package completely.

> I'm just wondering how many years it will be before SAVI is an 
> off-the-shelf multivendor solution.

There are already several vendors on their list with full or partial 
support. Also, some SAVI functions has been around for 5-10 years for some 
vendors, what they're doing is less to invent new IPv4 functions but to 
actually make them a standard and document them.

IPv6 is another ballgame, there new stuff is happening.

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Sep 2010 13:55:24 +0800

Mikael,

[changing subject as this has departed from discussing the RS mark draft]

> Well, the DHCPv6 standard can be changed to hand out information so ND isn't needed. This is what I had in mind. This would remove the need for the whole RA/ND/RS package completely.

I don't understand what you mean when you say ND isn't needed.
basic ND has this set of functions:

    Router Discovery
    Prefix Discovery
    Parameter Discovery
    Address Autoconfiguration
    Address resolution
    Next-hop determination
    Neighbor Unreachability Detection
    Duplicate Address Detection
    Redirect

are you proposing that DHCPv6 is extended to cover all of them?
if not, then which ones?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Sep 2010 08:51:12 +0200 (CEST)

> are you proposing that DHCPv6 is extended to cover all of them?

All of them.

Think the equivalent of IPv4 "static ARP" and "default route". No on-link 
prefix, so no other neighbours apart from your gateway need to be known or 
found.

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Sep 2010 17:38:56 +0800

Mikael,

> Think the equivalent of IPv4 "static ARP" and "default route". No on-link prefix, so no other neighbours apart from your gateway need to be known or found.

in IPv4 access networks you do ARP from the CPE at least. how did you intend for the CPE to learn the default router's mac address? glean it from DHCP?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Sep 2010 12:00:35 +0200 (CEST)

On Tue, 21 Sep 2010, Ole Troan wrote:

> in IPv4 access networks you do ARP from the CPE at least. how did you 
> intend for the CPE to learn the default router's mac address? glean it 
> from DHCP?

Yes.

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 21 Sep 2010 20:11:59 +1000

> the whole RA/ND/RS package completely.

=> Before getting into the merits of your idea, why do you want to do that?
A pointer to some requirements or an email with the foreseen benefits would
be useful. 

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Sep 2010 13:36:53 +0200 (CEST)

On Tue, 21 Sep 2010, Hesham Soliman wrote:

> => Before getting into the merits of your idea, why do you want to do 
> that? A pointer to some requirements or an email with the foreseen 
> benefits would be useful.

I mentioned it earlier in this thread (about 8 messages back), please see 
the message from "Mon, 20 Sep 2010 07:31:05 +0200 (CEST)".

"The whole L2 environment would need a lot less code, it basically would 
only need to be able to filter the above mechanisms, not inspect them."

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 21 Sep 2010 22:33:26 +1000

> only need to be able to filter the above mechanisms, not inspect them."

=> Sorry I missed that email and a few others. But you're trying to optimise
something that already exists? I don't see the benefit of removing code at
the expense of having less reliable networks. I say less reliable because ND
allows for detecting changing conditions on the link without having to rely
on a central server. Doesn't look like a worthwhile activity IMHO.

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Sep 2010 14:55:37 +0200 (CEST)

On Tue, 21 Sep 2010, Hesham Soliman wrote:

> => Sorry I missed that email and a few others. But you're trying to 
> optimise something that already exists? I don't see the benefit of 
> removing code at the expense of having less reliable networks. I say 
> less reliable because ND allows for detecting changing conditions on the 
> link without having to rely on a central server. Doesn't look like a 
> worthwhile activity IMHO.

I don't want to remove code in the end nodes, I want to simplify the 
implementation of filtering in L2 devices in the ISP access network.

Most vendors do not have this support yet for IPv6.

You might not think this is worthwile because you don't have this 
deployment model in your network. That doesn't mean it's not worthwile to 
ISPs with millions of subscribers who use an L2 ETTH deployment model.

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Sep 2010 16:31:52 +0200

Le 21 sept. 2010 à 14:55, Mikael Abrahamsson a écrit :

>> => Sorry I missed that email and a few others. But you're trying to optimise something that already exists? I don't see the benefit of removing code at the expense of having less reliable networks. I say less reliable because ND allows for detecting changing conditions on the link without having to rely on a central server. Doesn't look like a worthwhile activity IMHO.
> 
> I don't want to remove code in the end nodes, I want to simplify the implementation of filtering in L2 devices in the ISP access network.
> 
> You might not think this is worthwile because you don't have this deployment model in your network. That doesn't mean it's not worthwile to ISPs with millions of subscribers who use an L2 ETTH deployment model.

It seems to be too late anyway:
- A LAN without ND/RA wouldn't support currently existing hosts
- A host without ND/RA wouldn't work on currently existing LANs

Not preserving backward compatibility would IMHO be a very bad idea.

Regards,
RD

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Sep 2010 11:00:58 -0400

> were still configuring IPv4 hosts manually. ND/RA seemed like an

token ring seemed like a good idea too.  but ethernet won.  here in the
operational net, dhcp dominates.  maybe, 15 years later, it's time for
another leap forward.

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Sep 2010 17:45:41 +0200 (CEST)

> - A LAN without ND/RA wouldn't support currently existing hosts

Why not? DHCP could populate the neighbour table with very long lifetime?

The only change I see would be for the operation of DHCPv6 to always run 
if there isn't any response to RS and no RA is seen.

Perhaps some minor changes need to be made to allow for populating the 
neighbour table statically (and set the timeouts to whatever is in the 
DHCP lease), but I don't see this as a major change in the IPv6 stack.

You're right, this doesn't work on unmodified hosts with standards that 
exists today, but the changes needed should be minor...

> - A host without ND/RA wouldn't work on currently existing LANs

That's not what I'm proposing. I'm not talking about ripping out anything.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 21 Sep 2010 14:22:25 -0500

> exists today, but the changes needed should be minor...

I think your idea makes most sense in cases where Internet access is provided via cable head-ends or PONs. Where everything from customer premises has to go through the head-end anyway. Yes, the need for ND in this particular case is probably questionable, at least within the provider's coax network or PON.

Otherwise, I don't see the advantage of overloading the DHCP server with this new responsbility of keeping track of all physical addresses in the local net, other routers, etc. As Hesham pointed out, this concentrates more responsibility on a central server, a responsibility that is now distributed among all of the hosts (and routers) instead.

My position is, I need to have a reliable way of distributing "well known" IPv6 addresses to the hosts of peer-peer networks. That's my interest in DHCPv6, vs SLAAC, for assignment of addresses.

Bert

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Sep 2010 21:31:53 +0200 (CEST)

On Tue, 21 Sep 2010, Manfredi, Albert E wrote:

> I think your idea makes most sense in cases where Internet access is 
> provided via cable head-ends or PONs. Where everything from customer 
> premises has to go through the head-end anyway. Yes, the need for ND in 
> this particular case is probably questionable, at least within the 
> provider's coax network or PON.

In L2 ETTH networks it's done the same way, by means of "local-proxy-arp" 
and disallowing hosts to send arps to each other.

> Otherwise, I don't see the advantage of overloading the DHCP server with 
> this new responsbility of keeping track of all physical addresses in the 
> local net, other routers, etc. As Hesham pointed out, this concentrates 
> more responsibility on a central server, a responsibility that is now 
> distributed among all of the hosts (and routers) instead.

I'm perfectly fine with the router itself being DHCPv6 server.

> My position is, I need to have a reliable way of distributing "well 
> known" IPv6 addresses to the hosts of peer-peer networks. That's my 
> interest in DHCPv6, vs SLAAC, for assignment of addresses.

Well, it's not my interest. I want tracability and security, and I can 
only do that if my customers only communicate to each other via L3 via my 
router. I never want customer to talk direct L2 to each other. Q-in-q is 
expensive to terminate so I still want them to be in the same vlan.

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Sep 2010 22:45:17 +0200

Thanks for the explanation.
That's still too much a change IMHO.
Regards,
RDRD

Le 21 sept. 2010 à 17:45, Mikael Abrahamsson a écrit :

> The only change I see would be for the operation of DHCPv6 to always run if there isn't any response to RS and no RA is seen.
> 
> Perhaps some minor changes need to be made to allow for populating the neighbour table statically (and set the timeouts to whatever is in the DHCP lease), but I don't see this as a major change in the IPv6 stack.
> 
> You're right, this doesn't work on unmodified hosts with standards that exists today, but the changes needed should be minor...
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Sep 2010 11:16:26 +1200

> Not preserving backward compatibility would IMHO be a very bad idea.

I'm not against new-and-better, and I have some spare Token Ring PCMCIA
cards if you need them, but we already have an IPv6 legacy. Mikael
is arguing for a mode in which there is no ND/RA traffic whatever,
so that layer-violation code in layer 2 doesn't have to watch out
for it. That isn't realistic, IMHO, since there are millions of
devices out there that believe ND/RA is the right thing to do when
IPv6 is enabled. And we still need isolated IPv6 networks to self-configure,
so ND/RA is never going to go away, so there will always be devices
that start it up, even if DHCPv6 is enhanced as Mikael proposes.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Sep 2010 19:38:48 -0400

> IPv6 is enabled.

no one is arguing nd/ra be removed entirely, as subnet anycast should
be.  the argument is that there are environments where it is not needed
and dhcp should be able to be used in its place.

randy

---

From: Christian Huitema <[email-masked]>
Date: Wed, 22 Sep 2010 01:06:12 +0000

> no one is arguing nd/ra be removed entirely, as subnet anycast should be.  
> the argument is that there are environments where it is not needed and 
> dhcp should be able to be used in its place.

That's reasonable. There are cases where auto configuration does not work well. A centrally configured solution can mitigate various kind of RA/ND spoofing attacks, in the same way that static configuration can mitigate ARP spoofing attacks.

-- Christian Huitema

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Sep 2010 21:10:34 -0400

> That's reasonable. There are cases where auto configuration does not
> work well. A centrally configured solution can mitigate various kind
> of RA/ND spoofing attacks, in the same way that static configuration
> can mitigate ARP spoofing attacks.

also, do not underestimate the co$t of the of operational change to move
from dhcp4 to nd/ra.  folk who want to keep dns and ip audit may have to
go static without dhcp6.  another non-trivial barrier to ipv6 deployment.

randy

---

From: Karl Auer <[email-masked]>
Date: Wed, 22 Sep 2010 11:48:23 +1000

> go static without dhcp6.  another non-trivial barrier to ipv6 deployment.

Randy, could you elaborate please? Not sure I see what you are getting
at. Do you mean that if people do not use DHCPv6, they will have a
problem tracking which IP addresses are in use?

Regards, K.

---

From: Doug Barton <[email-masked]>
Date: Tue, 21 Sep 2010 19:03:13 -0700

On 9/21/2010 4:16 PM, Brian E Carpenter wrote:
> we already have an IPv6 legacy

As much as I wish it were otherwise, I don't think there is yet enough 
of a deployment at this point to really make this a show-stopper.

But even if we do, I don't see any reason we couldn't have a no-ND 
solution in a greenfield deployment.

Even the topic of this sub-thread indicates the disconnect between a 
still-large percentage of the operator community and the ND/RA zealots. 
The fact that it keeps coming up over and over should (at some point) be 
a sign that people who actually want to deploy IPv6 would like to be 
able to do it on a DHCP-only basis. No one is saying yank ND/RA out of 
the spec, just make it optional.

Doug

--

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Sep 2010 14:29:47 +1200

> solution in a greenfield deployment.

Yes, of course we could, after a certain amount of work on
DHCPv6 specs and products. Somebody who cares should probably write
up a draft on excatly what's needed. But my point is that any such
network still needs to deal with hosts that choose to generate ND and
RS packets. As I understood Mikael, he wanted to remove all snooping
of such packets from layer 2 devices. Well, if you do that, those
packets will still be there, and if they are a security risk, the
risk will still be there. And you'd probably still need to watch out
for rogue RA packets, because some hosts might be vulnerable to
them.

So I can certainly see how we could make ND/RA redundant for certain
types of managed network, but I don't see how we can behave as if
they don't exist, at least from a security viewpoint.

> the spec, just make it optional.

Once again, it isn't optional for certain types of deployment, and the same
is true for DHCPv6 of course. I don't think our set of RFC 2119 keywords
can quite capture this scenario-dependency.

    Brian

---

From: Doug Barton <[email-masked]>
Date: Tue, 21 Sep 2010 19:34:37 -0700

> can quite capture this scenario-dependency.

I think you and I are in more agreement than disagreement, and I am not 
saying that the path forward from here is trivial; just that it is 
wanted. :)

Doug

--

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 22 Sep 2010 13:24:42 +1000

I agree. You want this "minor" change to be done in all host stacks. At this
stage IMO it's way too late. I'm dealing with some vendors now and I don't
hear any complaints about supporting ND in their routers/switches, that's
anecdotal but we didn't see this on the mailing list either. I can't see how
ND is a show-stopper or even delaying any router vendor.

Hesham

On 22/09/10 6:45 AM, "Rémi Després" <[email-masked]> wrote:

>> The only change I see would be for the operation of DHCPv6 to always run if
>> there isn't any response to RS and no RA is seen.
>> 
>> neighbour table statically (and set the timeouts to whatever is in the DHCP
>> lease), but I don't see this as a major change in the IPv6 stack.
>>

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Sep 2010 14:29:05 +0930

On Tue, 21 Sep 2010 19:03:13 -0700

> of a deployment at this point to really make this a show-stopper.

Depends on what you define as deployment. Inactive IPv6 code sitting in
devices that have left the vendor is deployed IPv6 code - it just
hasn't been enabled or encountered an RA.

If the ideas in this thread get any legs, it'd be far better if they
were called "IPv7" because they're making significant functional
changes to IPv6's model of operation that deployed IPv6 code expects.

> still-large percentage of the operator community and the ND/RA zealots. 

Why aren't the "still-large percentage of the operator community" not
bothering to contribute?

Fred Baker posted a working group last call on a draft recently (12th
Sept, ipv6-ops, draft-ietf-v6ops-incremental-cgn WGLC) to one of the
IPv6 operator mailing lists. I wonder how many operators bothered to
read it and contribute?

p.s. calling people you don't agree with "zealots" won't win any
arguments or convince anybody of the value of your position - it's
resorting to name calling, nothing more.

> the spec, just make it optional.

They are already optional. Those people who don't want to use
ND/RAs are likely to already have knobs to switch them off (Cisco
switch off RAs by default on some interface types already) and will
have static configuration mechanisms. 

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 07:20:06 +0200 (CEST)

> for rogue RA packets, because some hosts might be vulnerable to

I want to stop snooping them, yes, but I also want to filter them 
completely.

Right now if we were to deploy IPv6 in ETTH environment we would either do 
it with Link Local only between us and the WAN port on the customer (M and 
O bit set in RA), and use DHCPv6-PD to hand out IP addresses to the 
customer and the CPE router would need to be able to use the weak host 
model to send packets to the Internet. The L2 network would have to 
inspect/filter unwanted packets such as any packets not originated from 
the DHCPv6-PD prefix handed out, but it would still have to allow all LL 
traffic needed for the ND machinery to work. This model doesn't need 
anything changed for hosts/routers, but needs quite a lot of enhancements 
in the L2 network.

Another model is the one I proposed here, where DHCPv6 is allowed to 
configure everything on the host needed for Internet connectivity. This 
requires minor changes in the DHCPv6 implementation and also perhaps in 
the ND state machinery (remove all dynamics). It means the L2 network 
won't have to do any ND state machinery inspection at all, it only needs 
to look into DHCPv6.

> they don't exist, at least from a security viewpoint.

Of course not.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 07:21:36 +0200 (CEST)

> ND is a show-stopper or even delaying any router vendor.

ND is an integral part in any IPv6 implementation. Nobody is saying ND 
shold go away, what we're saying is that it should be possible to run 
without it in some scenarios.

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 22 Sep 2010 15:26:53 +1000

> without it in some scenarios.

=> I understand that, but I think that to make this work you will need to do
that with zero modifications to the host's IPv6 stack. I don't think you can
count on people modifying their host implementations to support this
scenario. 

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 07:28:19 +0200 (CEST)

> Why aren't the "still-large percentage of the operator community" not

This has already been re-iterated time and time again. Operators are 
generally not protocol architects, they are in the business of building 
and maintaining networks to deliver a service. They are not in the 
business of designing protocols. They might come to the IETF and wish for 
functionality and can generally describe what they want to do. They 
generally do not write RFCs.

> IPv6 operator mailing lists. I wonder how many operators bothered to

When operators (like me) come here and want things, we get shot down by 
"too late" and "you're wrong".

> resorting to name calling, nothing more.

So it's better to blame people for not wanting to engineer and design 
exactly what it is they need? That's like saying a racing driver is to 
fault because he didn't help design the ball-bearing in the engine crank 
shaft and it broke during a race.

> They are already optional. Those people who don't want to use ND/RAs are 
> likely to already have knobs to switch them off (Cisco switch off RAs by 
> default on some interface types already) and will have static 
> configuration mechanisms.

.. and what (I, and others) are saying is that we would like DHCPv6 to be 
able to do the same "static" configuration.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 07:29:14 +0200 (CEST)

> ND is a show-stopper or even delaying any router vendor.

Nobody is saying a router shouldn't do ND. What we're saying is that an L2 
network shouldn't have to do ND inspection, so it should be possible to 
make things work without ND.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 07:30:05 +0200 (CEST)

On Wed, 22 Sep 2010, Hesham Soliman wrote:

> => I understand that, but I think that to make this work you will need 
> to do that with zero modifications to the host's IPv6 stack. I don't 
> think you can count on people modifying their host implementations to 
> support this scenario.

Do you count the DHCP client as part of the stack?

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 22 Sep 2010 15:31:54 +1000

> Do you count the DHCP client as part of the stack?

=> Not in the above statement I don't.

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 07:39:43 +0200 (CEST)

> => Not in the above statement I don't.

Ok, so if what I'm saying can be achieved by filtering ND in the L2 
network and be enabled by just changing the DHCPv6 client, you'd have less 
problems with it?

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 22 Sep 2010 15:44:15 +1000

> able to do the same "static" configuration.

=> But you're saying that as an operator need, when in fact your rationale
is to reduce vendor code. Is any vendor complaining about this? Is this an
operational need or is the problem that L2 device vendors told you they they
won't support those features? It would be good to know eactly where the
problem lies. Stating that you don't want "L2 devices to filter those
messages" isn't a problem description. If none of your devices support it
but you can get devices that do, then it's a product roadmap issue.

I'm trying to understand where the problem is.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 22 Sep 2010 15:46:36 +1000

> network and be enabled by just changing the DHCPv6 client, you'd have less

=> I would have less problems with it in that case. But I would have much
lesser problems if you answer my last email.

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 07:56:40 +0200 (CEST)

> is to reduce vendor code. Is any vendor complaining about this? Is this an

Well, yes, I want to reduce vendor code and to simplify the deployment. In 
my deployment model there also is no dynamic happening on the ISP-WAN 
segment, so there is little need for ND.

There are very few vendors that support at all the SAVI L2 functions 
needed, I want to ease the implementation.

But yes, you're correct, this is to simplify the code so there is shorter 
time to market and less test cases for us to run to make sure the vendor 
software runs properly. I'm also hoping it'll make the devices cheaper.

> I'm trying to understand where the problem is.

Multiple levels. ND is one more thing to go wrong. The less functionality 
needed, the easier it is for all involved. Static filtering is easier than 
dynamic inspection and filtering based on that. It means less punting 
packets to CPU in the L2 devices, less DoS vectors, less everything.

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Sep 2010 10:02:04 +0200

> That's reasonable. There are cases where auto configuration does not work well. A centrally configured solution can mitigate various kind of RA/ND spoofing attacks, in the same way that static conf…

The proposal includes a change in hosts.
Of course, if MS and Apple announce an upgrade of all their IPv6 stacks, to the effect that they use DHCPv6 requests to obtain what they no longer get in RAs, that would mitigate the need for backward compatibility.
But is this realistic?

Regards,
RD

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 11:24:37 +0200 (CEST)

On Wed, 22 Sep 2010, Rémi Després wrote:

> Of course, if MS and Apple announce an upgrade of all their IPv6 stacks, 
> to the effect that they use DHCPv6 requests to obtain what they no 
> longer get in RAs, that would mitigate the need for backward 
> compatibility. But is this realistic?

As far as I know Apple doesn't support DHCPv6 at all.

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Sep 2010 11:40:34 +0200

Le 22 sept. 2010 à 11:24, Mikael Abrahamsson a écrit :

>> Of course, if MS and Apple announce an upgrade of all their IPv6 stacks, to the effect that they use DHCPv6 requests to obtain what they no longer get in RAs, that would mitigate the need for backward compatibility. But is this realistic?
> 

You are misinformed, and that's IMHO important information: I have been using IPv6 from my MacBook SINCE DECEMBER 2007.

You may look at RFC 5569 and to http://www.cu.ipv6tf.org/pdf/CAJ7TP8E.pdf to see how it happened.

Regards,
RD

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 12:10:41 +0200 (CEST)

On Wed, 22 Sep 2010, Rémi Després wrote:

> You are misinformed, and that's IMHO important information: I have been 
> using IPv6 from my MacBook SINCE DECEMBER 2007.

http://ipv6int.net/systems/mac_os_x-ipv6.html
"Mac OS X does not include DHCPv6 software in the base operating system."

http://ls.berkeley.edu/mail/magnet/2008/0629.html
"Cheshire appears to be justifying Apple's complete
lack of support for DHCPv6 in MacOS."

Yes, you might have been using IPv6 but have you been using DHCPv6? The 
link you provided doesn't include the word "DHCP" (or DHCPv6) at all.

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 22 Sep 2010 20:31:19 +1000

> software runs properly. I'm also hoping it'll make the devices cheaper.

=> Ok, thanks for explaining that. Two comments:
1. Having worked for both vendors and operators, I can assure you that you
will not reduce the price of the products based on this optimision.
2. It is clear to me that this is not something for a specific deployment,
this is purely a business support decision. I'm not saying you're wrong to
try this, but I have my doubts about creating standards based on short term
business objectives. It is short term, because if you wait you will get your
products. 
Based on my IETF experience I would say you're more likely to get the "new"
products before you can get a new standard passed and implemented.

> needed, the easier it is for all involved.

=> Well, the question is whether it is needed functionality. You say you
don't need it, which is fine, but you have to admit that you're losing
reliability here. It's up to you to make that trade-off in your deployment,
but as a standards organisation, we have a different trade-off to make.
Whenever two proposals become so vastly contradictory, there must be very
strong justification IMO. I see the justification above as a short term
business need and is not based on the nature of the deployment, it's based
on product availability.
I don't think this is a good reason but I'll let others say what they think.

Static filtering is easier than
> packets to CPU in the L2 devices, less DoS vectors, less everything.

=> Dynamic filtering is not done by hand, it's done in code and once it's
there it's there. There is initial effort by the vendor and that's it.

Hesham

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Sep 2010 20:13:53 +0930

On Wed, 22 Sep 2010 12:10:41 +0200 (CEST)

> link you provided doesn't include the word "DHCP" (or DHCPv6) at all.

And this is the problem. Now you want to create a third (fourth?*)
autoconfiguration option, and it is already hard enough to get two
supported universally.

I'm surprised people don't see the logic problem when they say "method
XYZ isn't supported widely because the code hasn't been written, so
lets fix that problem by inventing another new method" - for which
neither the specifications or the code hasn't been written either.

* Assuming a baseline of DNS being the only additional parameter over
  addresses, you'd end up with -

o RA/SLAAC/RA DNS
o RA/SLAAC/Stateless DHCPv6
o RA/Stateful DHCPv6
o Stateful DHCPv6 Only

Ludwig Mies van der Rohe was right, "Less is more".

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 12:51:55 +0200 (CEST)

>  addresses, you'd end up with -

I never supported RA DNS, I think it is a genuinely bad idea.

> o RA/SLAAC/Stateless DHCPv6

I see quite a lot of code overlap in the last two.

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Sep 2010 06:59:13 -0400

> But you're saying that as an operator need, when in fact your
> rationale is to reduce vendor code. Is any vendor complaining about
> this?

your monotonically increasing bug count results in my operational need.

randy

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 22 Sep 2010 13:01:32 +0200

Hi,

> I never supported RA DNS, I think it is a genuinely bad idea.

And you probably have some arguments to share ...

Cheers,

a+

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Sep 2010 07:01:04 -0400

> problem tracking which IP addresses are in use?

for audit purposes, one wants to know which host did the dirty on
wednesday at 17:23.  most large enterprises base firewall rules on ip
address.  blah blah blah.

randy

---

From: Karl Auer <[email-masked]>
Date: Wed, 22 Sep 2010 23:28:25 +1000

> wednesday at 17:23.  most large enterprises base firewall rules on ip

Hm. Any host can take an address in its subnet - i.e. bypass DHCP. This
is as true of IPv6 as it is of IPv4. Any host that does SLAAC is
"bypassing" DHCPv6. So something has to watch the DHCP traffic and
dynamically permit addresses that have been allocated via DHCP. Is it
that step that concerns you? I.e., if hosts are doing SLAAC their DHCP
activity doesn't exist, so instead hosts will have to be assigned static
addresses and permitted in firewalls etc statically?

I don't want to set up a straw man here; I'm genuinely interested, but
having trouble joining the dots from your two messages.

Regards, K.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 15:35:20 +0200 (CEST)

> And you probably have some arguments to share ...

DHCPv6 stateless seem more suited to put all these options in, DNS is just 
one (probably the most important one though), and since operating systems 
seem to handle RA in the kernel and not in userspace, extending RA to do 
more things is harder than doing it in DHCP (which is generally handled in 
userspace).

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 15:37:28 +0200 (CEST)

> addresses and permitted in firewalls etc statically?

If one uses DHCP and have SAVI enabled equipment, then one knows who had 
what IPv6 address at what time, because the network will filter any 
traffic coming from addresses not handed out by DHCP and one knows what 
physical port was allocated the IP address at the time.

So SLAAC is out of the question for these types of applications. M and O 
flag set.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 22 Sep 2010 09:42:00 -0400

> is as true of IPv6 as it is of IPv4. Any host that does SLAAC is

Sure... but 99.99% of hosts (in the scenario randy brings up) will
just use whatever info the host gets for config, they won't go off
inventing things on their own.

> dynamically permit addresses that have been allocated via DHCP. Is it

oh: "If your address isn't in the firewall, you can't pass through"

> addresses and permitted in firewalls etc statically?

yea... so in the ipv4 world of enterprise networking lots of times the
host's have "static addresses" mapped to them via DHCP. This way some
set of privileges can be assigned (or just: "your machine is called
bob, ping bob, see, your machine is working" as an example) via
firewall/etc rules (or hosts.allow or ...). Or, control over what/who
gets access to the LAN. Permitting random things to connect to your
LAN (easily) and dhcp an address from an address pool is very often a
bad plan.

I can see that in the ipv6 world I'd want to do the same sort of
thing, assign addresses (and retain the capability to shift dns, tftp,
wins, etc) around from a central control point. I'd also like to not
have random things plugged into my LAN get globally reachable
addresses (and/or access to my internal LAN's secrets, etc).

-Chris

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Sep 2010 15:49:10 +0200 (CEST)

On Wed, 22 Sep 2010, Christopher Morrow wrote:

> I can see that in the ipv6 world I'd want to do the same sort of thing, 
> assign addresses (and retain the capability to shift dns, tftp, wins, 
> etc) around from a central control point. I'd also like to not have 
> random things plugged into my LAN get globally reachable addresses 
> (and/or access to my internal LAN's secrets, etc).

Exactly, this is why people who need to have some kind of tracking need 
DHCP.

<http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/chap5.html> 
describes some of the mechanisms used for IPv4 to achieve this.

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 22 Sep 2010 16:03:53 +0200 (CEST)

On Wed, 22 Sep 2010, Mikael Abrahamsson wrote:

> seem to handle RA in the kernel and not in userspace, extending RA to do more 
> things is harder than doing it in DHCP (which is generally handled in 
> userspace).

Not necessarily handled in kernel space:
- One of the first *BSD (INRIA) ipv6 implementation handled RA in 
userspace 
- Also IBM AIX 4.x handled RA in user space.

Best Regards,
 	Janos Mohacsi

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 22 Sep 2010 17:33:37 +0200

Hi,

Mikael Abrahamsson <[email-masked]> writes:

> DHCPv6 stateless seem more suited to put all these options in, DNS is
> just one (probably the most important one though), and since operating
> systems seem to handle RA in the kernel and not in userspace,
> extending RA to do more things is harder than doing it in DHCP (which
> is generally handled in userspace).

Exporting stuff received in RA from kernel to userspace is not an
issue but that's not the point. RA *processing* is usually in kernel
space because the IPv6 stack is there, the mechanism is part of IPv6
specification and it mainly serves address/link configuration purposes
which is usually done in the kernel.

Most IPv6 nodes needs 2 main things to operate:

 1) An address in subnet prefix (no matter which address)
 2) A DNS server

RA provide 1) in *all* the subnets I have seen so far. SLAAC is a
builtin in all stacks (one would say even Mac OS X has it ;-) ), it is
light and efficient.

When one has 1), providing 2) via RFC 5006 is straightforward: 
support to export ND options to userspace was added to Linux kernel in
October 2007 (commit 31910575, 137 lines added). A simple RDNSS
userspace client is few lines of code.

Now, when a network (not a client) has specific needs:

 - pushing various options which are useless for most clients
 - give specific address to specific nodes
 - support prefix delegation
 - ...

it may be worth using a common framework to do that and in that case the
initial complexity of DHCPv6 (RFC 3315 is more than 100 pages) might be
ok.

In the end, the needs of most leaves of the networks (laptops, phones,
sensors, ...) are *usually* satisfied by ND alone and the features
brought by DHCPv6 get *usually* useful somewhat "higher" in the network
(possibly for routers and servers).

I don't see the point in trying to replace ND by DHCPv6. DHCPv6 should 
replace manual configuration where it is still there because ND is not
sufficient: the set of needed options should be deduced from the needs
of those environments. 

a+

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Sep 2010 19:19:30 +0200

In your previous mail you wrote:

=> things are not so simple, i.e., I have a concern about the 'at all':
 - Apple doesn't provide DHCPv6 (client, server or relay) in its
  MacOS X distrib (this can change but on the MacOS X 10.6.4 I am
  writing this it is the case)

 - MacOS X uses standard BSD networking code & tools so you can run
  a DHCPv6 client on it, get and set an IPv6 address, etc.
  To summary, ifconfig behaves as on any other BSD.

 - MacOS X even provides 'ndp' command so you should be able to run
  the DHCPv6 does everything stuff on it (even I'd like to understand
  how DHCPv6 would bootstrap from nothing without ND :-)

 - there is a known issue with DNS server discovery: to summary again
  to update /etc/resolv.conf is very far to do what you want...
  But this doesn't mean it is impossible: you have to use the
  System Configuration framework (via tools or with a piece of code)
  and patch its Dynamic Store but it is something I'd not like to
  recommend and definitively to support. So we can say this is not
  integrated (BTW I suggest another thread if we'd like to discuss
  this point).

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Sep 2010 19:33:07 +0200

=> the second is a consequence of the first. BTW I wrote a full ND in
user mode for IPv6 over ATM so you can put any of the many ND functions
where you'd like (:-).

Regards

PS: I was the main author of the 'INRIA' IPv6 implementation.
PPS: I had a discussion about where to put the 'interesting' RA functions
with the KAME team. There were no killing arguments from a side, and
as you can find ND in BSD security advisories I still believe I was
not wrong.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Sep 2010 19:55:44 +0200

> I never supported RA DNS, I think it is a genuinely bad idea.

If RA DNS ever happens in widely available radvd implementations then I 
am keen to try it.  It is useful in a setting where DHCPv6 is not available.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Sep 2010 20:04:35 +0200

Le 21/09/2010 00:49, Brian E Carpenter a écrit :
>>> fully deployable for IPv6, except work by the vendor(s)? Is
>>> there any work needed on the basic IPv6 standards?
>>
>> environment without RA/RS, it would also help if one didn't need
>> NS either. The whole L2 environment would need a lot less code, it
>> basically would only need to be able to filter the above
>> mechanisms, not inspect them.
>
> I think the technical issue there is that ND and RA were designed as
> a package, and you certainly can't run without ND.
>
> [Historical note: the ND/RA design was done at a time when all we had
> deployed was ARP, because DHCP was not yet mature, and most of us

I wanted to add there still exist large PC-LAN-enterprise deployments
where the IPv4 address _is_ configured manually - no DHCP.  The
reticence facing DHCP has to do with many things, among which security
and pure human interaction.

I am not sure what IPv6 will bring into these deployments - probably
SLAAC, probably DHCPv6.  I think both should work equally -
independently or together as complete solutions for autoconfiguration.

Alex

>
>>
>>>> But as Fred also mentioned, SAVI WG is working in specifically
>>>> this area <https://datatracker.ietf.org/wg/savi/charter/>
>>>
>> Well, duplicating work is probably a bad idea. They have running
>> code, I don't see why people who want to fix this shouldn't join
>> them in their effort. Am I missing something?
>
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Sep 2010 20:15:19 +0200

> are you proposing that DHCPv6 is extended to cover all of them?

This question is difficult, because the list is long and you basically 
ask a value DHCPv6vsND for each item.

DAD: Maybe one would make DHCPv6 to distribute an address _and_ the 
result of DADing directly?

If DHCPv6 does Prefix Discovery, then it would like to make sure the 
prefix it offers is different than that of Prefix Delegation - different 
prefixes of a different concept.

Parameter Discovery: does DHCPv6 offer already MTU and Hop Limit values? 
  If not then it would make sense to offer it.

Address Resolution: no, DHCPv6 would not be good to resolve IP address 
to MAC address.  It's essentially a linkscoped operation.

...

Redirect: it's essentially a linkscoped operation.  A DHCPv6 Server on 
another link would have a hard time hearing the causes which provoke 
redirects.

There's another line appearing hidden through the items in the above list:

                 the default route

I'd like the IPv6 default route delivered by DHCPv6, in tandem with ND 
(that RA 'M' flag made sense).

Alex

---

From: Benny Amorsen <[email-masked]>
Date: Wed, 22 Sep 2010 22:03:53 +0200

Mikael Abrahamsson <[email-masked]> writes:

> only do that if my customers only communicate to each other via L3 via
> my router. I never want customer to talk direct L2 to each other.
> Q-in-q is expensive to terminate so I still want them to be in the
> same vlan.

Even if you have equipment which can terminate q-in-q (or some other
tunneling solution like EoMPLS is used), customers will likely require
dual-stack for a while.

If you want to give customers public IPv4 addresses and they each get
their own broadcast domain, you will have to give them 4 public IPv4
addresses per 1 usable address. At this point in time such a deployment
model is rather unattractive.

Combining a shared-VLAN model for IPv4 with a separate-VLAN model for
IPv6 for the same customers seems difficult to me.

/Benny

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Sep 2010 07:30:45 +0930

On Wed, 22 Sep 2010 15:49:10 +0200 (CEST)

> describes some of the mechanisms used for IPv4 to achieve this.

If your concerns about end-node trust are as strong as they seem to be,
wouldn't you be using 802.1x link layer authentication to identify and
track the end-user? Wouldn't that be a much more effective mechanism to
track who was attached to the network, when and for what duration?

I haven't had a chance to look into it yet, however I've been wondering
if link layer authentication credentials could be used to do things
like bootstrap SeND, providing the level of address/traffic
auditability you're after. That would take advantage of existing
mechanisms, rather than making fundamental changes to IPv6
operational models such as ND/RAs etc. Mechanisms like RFC4649 -
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent
Remote-ID Option" and similar could also be used in that scenario, with
the layer 2 device acting as a DHCPv6 relay. With it acting in that
role, it would then be able to automatically configure basic and simple
IPv6 source address filters and apply them to the link layer port.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Sep 2010 07:44:52 +0930

> which is usually done in the kernel.

I think the kernel space/user space decision is about ubiquity. When it
RAs/SLAAC is implemented in the kernel, then it's always there. If
DHCPv6 had been implemented in kernels then we wouldn't have the
availability issue we've got now.

However, that's not a strong argument for kernel space address
configuration either. DHCP for IPv4 is pretty much ubiquitous yet it
isn't in the kernel - because it is installed by default by all OSes.

Since the primary justification for kernel space is performance, it'd
probably better and more secure if RA/SLAAC processing was moved into
user space. I think a single RA/SLAAC/DHCPv6 process would better solve
the stateless / stateful address configuration problem we've got now.
It probably exists because RA/SLAAC processing is in kernel space in a
lot of OSes where as DHCPv6 is seen to best reside in user
space. (hopefully the last statement about configuration mechanism
availability makes it on topic for this list)

Appletalk in the Linux kernel follows the model of having address
autoconfiguration operate as a process in user space.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Sep 2010 07:29:17 +0200 (CEST)

On Wed, 22 Sep 2010, Benny Amorsen wrote:

> addresses per 1 usable address.

No, you don't. RFC3069.

I deployed one-vlan-per-customer-subvlan with a shared /27 supernet on 
Extreme Networks equipment in ~2002, the same thing can be done on Cisco 
as well ("ip address unnumbered lo10" and static routes for each /32 to a 
specific vlan interface).

This was for a static address assignment model (one static public IPv4 
address per customer) for ADSL (ethernet DSLAMs), I'm sure there is the 
equivalent for DHCP, I just haven't had the need to deploy it so I haven't 
looked into it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Sep 2010 07:33:24 +0200 (CEST)

> track who was attached to the network, when and for what duration?

I don't want to manage user accounts and credentials, also I'm not sure 
802.1x in any way handles what the user can do once they're connected.

I'm talking about ETTH, one port in an L2 switch is a household. I know 
what port goes to each household, so "trust" is not the issue.

In IPv4 I hand out an IP address and I know to what port (option 82) this 
IP address is at, and the L2 environment makes sure this port can only 
source traffic from the IP it has been handed for the duration of the 
lease.

> IPv6 source address filters and apply them to the link layer port.

I'm sure this is one thing SAVI WG has looked at and is part of their 
requirements.

---

From: Benny Amorsen <[email-masked]>
Date: Thu, 23 Sep 2010 10:29:25 +0200

Mikael Abrahamsson <[email-masked]> writes:

> Extreme Networks equipment in ~2002, the same thing can be done on
> Cisco as well ("ip address unnumbered lo10" and static routes for each
> /32 to a specific vlan interface).

Thank you very much for that pointer! It looks like an excellent
solution.

Even DHCP should work, as long as the DHCP-server and the router agree
on which addresses go on which VLAN. It works with other encapsulations
too... The more I think about it, the more I like it.

/Benny

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 23 Sep 2010 10:32:11 +0200

Hi,

> availability issue we've got now.

ND is about *basic* operations of the IPv6 nodes to support its
communications on the link (including w/ routers). Most of the changes
done are usually against kernel structures (routing table, neighbor
cache, ...). This is IMHO the reason why it makes sense for it to be
in kernel space by default.

Then, if more needs to be done with ND (as long as it is useful and
logical extensions, to support basic and simple things) it is easier to
export the content of messages to userspace (ND options are simple
enough). Just as it is done for RDNSS in Linux kernel.

The question of where to best suppor SEND does not belong here I think.

> isn't in the kernel - because it is installed by default by all OSes.

Compared to ND, the additional stuff supported by DHCP are for providing
additional info for various higher level functions of the system or
devices that are very advanced nodes (router, servers, ...).

> the stateless / stateful address configuration problem we've got now.

You would still need the interfaces to interact with the routing table,
the neighbor cache, ... Most of those interfaces will probably be more
complex than the parsing of RA in kernel space (even if Microsoft
managed to prove me wrong with MS10-009).

> availability makes it on topic for this list)

I implemented support for both protocols in Scapy and AFAICT DHCPv6 does
not belong to kernel space: it is too complex and far from the basic
operations the kernel is here to do.

> autoconfiguration operate as a process in user space.

I am not familiar w/ the protocol.

Cheers,

a+

---

From: Philip Homburg <[email-masked]>
Date: Thu, 23 Sep 2010 11:05:14 +0200

>source traffic from the IP it has been handed for the duration of the 

I wonder. I don't know if this has been discussed or proposed before. 

Why can't the CPE act as some kind of proxy between the customer's network and
the ISP's WAN network?

If an ISP essentially wants to run point to point links over what is
technically a shared ethernet with some filtering, why not define a protocol
for doing that and make sure that that protocol is only between the CPE and
the ISP's access concentrator?

The CPE can then for example continue sending RS messages, and can terminate
NS messages by always returning the concentrator's MAC address, etc.

That way, knowledge of the WAN link isolated in the CPE, instead of spread
across all hosts and consumer routers.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Sep 2010 19:12:34 +0930

> in kernel space by default.

I was talking about RAs/SLAAC, not ND.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Sep 2010 19:51:34 +0930

On Thu, 23 Sep 2010 07:33:24 +0200 (CEST)

> source traffic from the IP it has been handed for the duration of the 

Here's a suggestion of something that might go close to what you want

- RA with M set, no Prefix Information Option

That should trigger the end node to use Stateful DHCPv6 for it's
configuration parameters, and as there is no PIO, the end-node is to
consider all other destinations off link other than its own address (as
per RFC5942 - "IPv6 Subnet Model: The Relationship between Links and
Subnet Prefixes."), so it'll use the default router to get everywhere
other than it's own addresses.

By setting the Router Lifetime to 0 in the RA, that'd stop the router
being used as a default router. However, then you'd need a DHCPv6
option to convey the default router. That still wouldn't eliminate the
need for the RA though, as it is still being used to express the
address configuration policy, so it pretty much makes a DHCPv6
default router option somewhat redundant. You may as well just set
the RA Router Lifetime to a non-zero value to express the identity of
the default router.

Regards,
Mark.

---

From: Sander Steffann <[email-masked]>
Date: Thu, 23 Sep 2010 12:57:12 +0200

Hi,

> the RA Router Lifetime to a non-zero value to express the identity of

Unless you want to assign different default routers to different clients. I don't know if this should be taken into account, but it is a possibility...

Regards,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Sep 2010 13:03:35 +0200 (CEST)

On Thu, 23 Sep 2010, Philip Homburg wrote:

> The CPE can then for example continue sending RS messages, and can 
> terminate NS messages by always returning the concentrator's MAC 
> address, etc.

One cannot trust equipment under customer physical control. Ask the 
creators of Sony PS3 and Microsoft Xbox 360 and ask them how easy it is.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Sep 2010 20:42:12 +0930

On Thu, 23 Sep 2010 19:12:34 +0930

> I was talking about RAs/SLAAC, not ND.

To qualify that, I'm saying RS/RAs could be processed in user space,
as part of a RS/RA/SLAAC/ Stateless/Stateful DHCPv6 process (i.e. an
"address and routing configuration" process), while ND NS/NA could be
left in kernel space.

(I've somehow got into the habit of thinking that the term "neighbor
discovery" is referring to layer 3 -> layer 2 address resolution. I
blame Radia Perlman, because that's mostly what she talks about in her
"Neighbor Discovery" chapter of "Interconnections" ;-) )

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Sep 2010 20:56:06 +0930

On Thu, 23 Sep 2010 12:57:12 +0200

> Unless you want to assign different default routers to different clients. I don't know if this should be taken into account, but it is a possibility...

I'd wonder if there are examples of that being done in IPv4. I can't
really think of a real world situation I've experienced in IPv4 where
I'd find that capability useful. Poor mans first hop router redundancy
might be a possibility, however usually if you care that much about that
redundancy, you'd buy a couple of routers that do HSRP, VRRP etc.
IPv6's basic anycast mechanism would provide a better solution than
half/half.

Phasing out an old router and bringing in a new one might appear to be
a situation where it'd be useful, however I'd think it'd be just as
easy to achieve by winding down the RA Router Lifetime of the old
router and announcing a new one until all the end-nodes have stopped
using the old one.

It also creates trust issues because you'd be selecting clients based
on one of a number of identifying parameters that they're in control
of. In the environments Mikael seems to be describing that level of
trust doesn't sound like it exists.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 23 Sep 2010 13:34:13 +0200

>creators of Sony PS3 and Microsoft Xbox 360 and ask them how easy it is.

I did not mean to trust the CPE. I mean that whatever layer violation you
want done, can be hidden in the CPE instead of exposing it to the host (or
router) behind it.

For example, a host may react to redirects. But if the CPE simply filters out
all redirects coming from the WAN, then the host does have to
modified/configured to ignore them.

Also, if you want to avoid sending NS messages over the WAN, then the CPE can
remember the MAC address of the DHCP relay and fake that to the host as the
MAC address of the default router.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Sep 2010 13:38:11 +0200 (CEST)

On Thu, 23 Sep 2010, Philip Homburg wrote:

> I did not mean to trust the CPE. I mean that whatever layer violation 
> you want done, can be hidden in the CPE instead of exposing it to the 
> host (or router) behind it.

I don't see how this would work/help. I cannot trust the CPE, so I still 
need to do all the same filtering as I would have to without the CPE.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 23 Sep 2010 14:29:03 +0200

>need to do all the same filtering as I would have to without the CPE.

Yes, you would still have to do the filtering. 

But it saves you from having to get agreement with all other people who
also do ethernet based interfaces for IPv6.

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 26 Sep 2010 16:04:22 -0700 (PDT)

Hi Mikael,
  Very thought provoking discussion indeed!

My suggestion is do it like in mobile networks: get the host initiate an RS 
rather than waiting for RA.

Regards,

Behcet

----- Original Message ----
> From: Mikael Abrahamsson <[email-masked]>
> To: Hesham Soliman <[email-masked]>
> Cc: 6man <[email-masked]>; Brian E Carpenter <[email-masked]>
> Sent: Wed, September 22, 2010 12:21:36 AM
> ND  is an integral part in any IPv6 implementation. Nobody is saying ND shold 
>go  away, what we're saying is that it should be possible to run without it in 
>some  scenarios.
> 
> -- Mikael Abrahamsson    email: [email-masked]