Subject: Liaison from BBF

From: David Allan I <[email-masked]>
Date: Mon, 9 Nov 2009 00:10:33 -0500

HI:

Attached are a series of charts that outlines a problem the Broadband Forum is wrestling with in the IPv6 space, the charts are in effect a companion to a liaison sent to INTAREA. I understand agendas are full so there will not be time to discuss this in meeting time during the course of this week, so it is posted such that there is a chance for reflection on the problem (for those so inclined) on the list...and have opportunity for face to face with any interested parties...

Please direct any questions for clairification to me...and I can arrange to be found on breaks

Cheers
Dave Allan
Co-chair BBF Arch & Transport Committee

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Nov 2009 10:00:25 -0500

Sorry, I still don't get it. We need more detail!

Two things stand out:

> If two devices happen to have the same Ethernet MAC address as a
> consequence of incompetent manufacture, the link-local address derived
> for that interface will also be non-unique, provided it is derived
> from the EUI-64 identifier. This has been identified as an
> inconveniently frequent scenario (impacting ~4% of access nodes at any
> given time)

this 4% figure seems *very* high. Can you please provide more details
on how you reached that number?

Also, if you have two devices on the same link sharing the same MAC
address, you have problems. Period. Having duplicate IP addresses is
only one symptom. If you fix that problem, but still have duplicate
MAC addresses in use, it is not clear to me that your network will
function correctly. Have you done the analysis to be sure that the
duplicate MAC address scenario is something that is solvable in
practice?

> When numerous hosts share an Ethernet broadcast domain, the BNG/edge
> router needs to support a mechanism that ensures duplicate link-local
> addresses can be handled correctly without necessarily depending on
> cooperative action by the hosts
> 
> it is explicitly required to do something to make this happen

Again, it is not clear to me what "handling correctly" even means.

Finally, the charts say you are worried about a "malicious user"
sending out bogus ND packets. ND simply can't deal with this sort of
hostile environment, and there is no easy way to fix this. Is that
what you are asking this group to fix?

For that matter, ARP doesn't address this problem either. Is there a
new problem that shows up with IPv6 that didn't exist with IPv4? And
if not, what is wrong with using the IPv4 solutions (assuming they
exist)?

Thomas

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Nov 2009 16:27:18 +0100 (CET)

On Mon, 9 Nov 2009, Thomas Narten wrote:

> this 4% figure seems *very* high. Can you please provide more details on 
> how you reached that number?

I have personal experience with managing ADSL provider. We noticed approx 
5% of all MAC addresses were identical, I've personally seen D-link 
NAT-boxes shipped with identical MAC addresses and a "clone PC MAC 
address" feature in the web GUI. D-link support response is "yes, our 
MAC-addresses are not unique enough".

It's out there, it needs to be handled. NOTHING the end user can change or 
in other way influence can be trusted, either it's their own fault or 
someone elses. This is why some manufacturers of DSLAMs etc do MAC-rewrite 
to handle this situation in flat L2 networks, ie the MAC number will in 
the aggregation network contain a MAC address that is tied to the customer 
access line, and cannot be influenced by the end customer. The customer 
MAC address will only be seen on the actual access line.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 9 Nov 2009 09:53:57 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 

> MAC-addresses are not unique enough".

I'm missing something that is probably obvious.

Doesn't the home modem, or "residential gateway," have hard-coded in it the unique IPv6 prefix for each home? If yes, then why would a home PC host not always have a unique IPv6 address, even if the MAC address might be duplicated in some other home on the broadcast domain?

And why would ND conducted inside a home go beyond the "residential gateway"?

I think I understand the problem being addressed here, but it seems to apply only if all the homes passed by the "last mile" broadcast domain is using the same IPv6 prefix.

Bert

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Nov 2009 17:42:27 +0100 (CET)

On Mon, 9 Nov 2009, Manfredi, Albert E wrote:

> Doesn't the home modem, or "residential gateway," have hard-coded in it 
> the unique IPv6 prefix for each home? If yes, then why would a home PC 
> host not always have a unique IPv6 address, even if the MAC address 
> might be duplicated in some other home on the broadcast domain?

First of all, we're talking MAC addresses here (ethernet address), not 
IPv6 address. And no, I haven't seen any residential rollout plan where 
IPv6 would be provisioned in the static way you describe, DHCPv6-PD seems 
to be the most popular method seen in discussion. And since the home 
gateway needs to talk to the ISP router in the PoP somehow, this might be 
over a shared broadcast domain, thus the worry about duplicate MAC 
addresses (both in aspect of L2 learning being broken, plus the home 
gateways choosing the same link local address to use on the WAN side).

> And why would ND conducted inside a home go beyond the "residential gateway"?

This is on the WAN-side of the home we're talking about, not in the home 
LAN.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 9 Nov 2009 11:09:51 -0600

> From: Mikael Abrahamsson [mailto:[email-masked]] 

Here is the crux of my not understanding the problem:

> And no, I haven't seen any residential rollout 
> plan where 
> to be the most popular method seen in discussion.

Does not the ISP control, own, and distribute the "residential gateway"? If yes, then the DHCP conducted within the broadcast domain part of the network, i.e. the "last mile" part *outside* customer premises, should be able to ensure uniqueness of the EUI and consequently the IPv6 address of each residential gateway WAN side, no? So that DHCP or whatever method of assigning IPv6 WAN side addresses should be safe.

For that matter, one could use the client identifier option, and the ISP could hard-code the client ID in each of their residential gateways, before distributing these to customer premises.

Why would ISP not own and control the residential gateway?

We received our ADSL "modem" in the mail, from Verizon. It is a NAT, and the WAN side is under their control entirely. Is this not standard practice among ISPs?

Bert

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Nov 2009 18:39:37 +0100 (CET)

On Mon, 9 Nov 2009, Manfredi, Albert E wrote:

> Does not the ISP control, own, and distribute the "residential gateway"?

Not in my market anyway (some have this service of course, but it's 
definitely not mandatory).

> Why would ISP not own and control the residential gateway?

Because it's cheaper to have the customer walk into their electronics 
store and buy any CPE they fancy, than to have the ISP handle it. It also 
gives customers more choice. In some markets, people like to have the 
choice between ISP provided CPE and one they run themselves.

> We received our ADSL "modem" in the mail, from Verizon. It is a NAT, and 
> the WAN side is under their control entirely. Is this not standard 
> practice among ISPs?

As far as I can discern, it's standard in the US but not in the rest of 
the world. Generally, the more competition in the market, the less likely 
it is that the ISP provides the end user CPE. If customers switch ISPs 
every year or so, they want to be able to re-use their CPE.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 9 Nov 2009 16:50:15 -0500

One common way of setting up a residential gateway is to first set up a
PC connected to the ISP, let it get an IPv4 address through DHCPv4, tell
the ISP about it and get the MAC address and DHCPv4 lease recorded (and
reserved) in the ISP servers (to get it online).  Then, the customer
hangs up the phone from the ISP and transfers the connection to the PC
from behind the modem to behind the residential gateway (on the LAN
side).  The WAN side of the residential gateway is then connected to the
modem of the ISP.  However, since the residential gateway no longer has
a MAC address that matches the lease recorded in the ISP DHCPv4 server,
the user simply clones the MAC address of the PC onto the WAN side of
the CPE Router.  The residential gateway completes DHCPv4, and
everything works fine.  The MAC address of the PC and the MAC address of
the WAN side interface of the residential gateway are the same.
However, this is not a problem as long as the residential gateway either
routes traffic or is a NAT box.  If the residential gateway is a bridge,
this causes all sorts of problems (including the problems listed in the
BBF liason).  However, if it were a bridge, then you wouldn't have to
clone the MAC address in the first place!

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mikael Abrahamsson
Sent: Monday, November 09, 2009 12:40 PM
To: [email-masked]
Subject: RE: Liaison from BBF

Because it's cheaper to have the customer walk into their electronics
store and buy any CPE they fancy, than to have the ISP handle it. It
also gives customers more choice. In some markets, people like to have
the choice between ISP provided CPE and one they run themselves.

> We received our ADSL "modem" in the mail, from Verizon. It is a NAT, 
> and the WAN side is under their control entirely. Is this not standard

As far as I can discern, it's standard in the US but not in the rest of
the world. Generally, the more competition in the market, the less
likely it is that the ISP provides the end user CPE. If customers switch
ISPs every year or so, they want to be able to re-use their CPE.

-- 
Mikael Abrahamsson    email: [email-masked]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Phil Bedard <[email-masked]>
Date: Mon, 9 Nov 2009 16:56:11 -0500

Answers inline

On Nov 9, 2009, at 12:09 PM, Manfredi, Albert E wrote:

> Does not the ISP control, own, and distribute the "residential  
> gateway"? If yes, then the DHCP conducted within the broadcast  
> domain part of the network, i.e. the "last mile" part *outside*  
> customer premises, should be able to ensure uniqueness of the EUI  
> and consequently the IPv6 address of each residential gateway WAN  
> side, no? So that DHCP or whatever method of assigning IPv6 WAN side  
> addresses should be safe.
>

Traditionally, they don't.  Some providers can provide a gateway but  
it's far cheaper to go to your local electronics store and get a home  
router with wireless than to "rent" one from a service provider.   
You'll find a SP-provided gateway more often with business services  
than residential services.

> For that matter, one could use the client identifier option, and the  
> ISP could hard-code the client ID in each of their residential  
> gateways, before distributing these to customer premises.
>

The just don't.

> and the WAN side is under their control entirely. Is this not  
> standard practice among ISPs?
>

Not for most ISPs in the US.  I would say the Verizon example is more  
the exception than the rule.  I've only ever used my own store-bought  
gateway.  For most cable providers in the US you don't even need to  
use their provided modem, you can bring your own and use it.

Phil

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 9 Nov 2009 16:18:46 -0600

That seems a little more complicated than it needs to be, but assuming that PCs are designed by people who know about uniqueness of MAC addresses, that solution should also work with IPv6 too, no?

Another possibility is that ISPs need to allow DAD to be run by residential gateways on the WAN side. Sort of similar to what you had to do for IP over ATM, the "broadband network gateway" (router port where the broadcast Ethernet domain comes together upstream of the residential gateways) needs to reflect back downstream all NS and NA messages from the WAN side of residential gateways.

Of course, this assumes that these off-the-shelf residential gateways know enough to perform DAD. But such a solution would only make the ISP's "broadband network gateway" unique. The residential gateways would just do NS and NA as if connected to a regular Ethernet.

(Or maybe all of this has been said but I didn't get it.)

Bert 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wes Beebee (wbeebee)
Sent: Monday, November 09, 2009 4:50 PM
To: Mikael Abrahamsson; [email-masked]
Subject: RE: Liaison from BBF

- Wes

-----Original Message-----

> Does not the ISP control, own, and distribute the "residential
gateway"?

---

From: David Allan I <[email-masked]>
Date: Mon, 9 Nov 2009 18:00:22 -0500

HI

There are a couple of scenarios to consider..

1) Simple bridging from the home, hence a number of NIC address will appear at the edge router...

2) Retail model for RGs, which is how I bought mine... My modem came from my DSL provider, but as it had no wireless, so I turned off all higher layer functions and front ended it with a Belkin box bought over the counter... 

Hope this helps
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manfredi, Albert E
Sent: Tuesday, November 10, 2009 2:10 AM
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: RE: Liaison from BBF

Here is the crux of my not understanding the problem:

> And no, I haven't seen any residential rollout plan where
> IPv6 would be provisioned in the static way you describe, DHCPv6-PD 
> seems to be the most popular method seen in discussion.

Bert

---

From: David Allan I <[email-masked]>
Date: Mon, 9 Nov 2009 18:31:23 -0500

HI Thomas:

Unfortunately having just changed jobs I'm having trouble exactly recreating all my sources of information...

The following was one anecdotal example offered during our discussions in the spring..."...in a real nationwide telco today with approximately 3.5million DSL ports there is about 300-400 duplicate MAC@ alarms active on the DSLAMs at any time, and this is only where 2 of the same MAC@ appear on the same DSLAM (384-1000 users each)..."

TO take it back up a notch...

In a perfect world where all MACs were properly unique and all implementations correctly constructed link local via EUI-64 we'd all be happy campers, it works as intended. Unfortunately that is not the case and we seem to have a hierarchy of grief.....

1) Some carriers have deployed MAC address translation in the Access node/DSLAM to ensure MAC uniqueness. This means ALG functionality is required for Ethernet OAM and other protocols, and while fixing MAC uniqueness, does not address duplicates in link local construction unless NAT of the lower 64 bits of LLA is included in the mix.

2) Our liaisons with IEEE on the subject and some proposals to the forum focus on the fact that uniquness only needs to exist in a given Ethernet broadcast domain, hence keeping a few extra VLANs in the back pocket to shift duplicate customers to solves the problem, and my math suggested this would inflate VID usage by a corresponding few percent. Issue being this then breaks down if the link local address is not constructed from the MAC, and RFCs have been trotted out at the BBF on NOT using the EUI-64 specifically to defeat traffic analysis attacks. This being an expected deployment scenario when wireless media in the home is considered and an emerging class of FMC capable terminals is deployed. 

So a solution analogous to DAD appears to be needed, that originates with the edge router, where if the detected duplicate does not subsequently behave in a prescribed manner service may then be denied in the interest of the common good. As DAD is already deployed that would appear to be a path of least resistance vs waiting years for a roll out of a fix. However if my memory serves correctly, unicast from the edge router would be a desirable form and I am unsure if that is supported in standards or implementations...

Cheers
D

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Tuesday, November 10, 2009 12:00 AM
To: David Allan I
Cc: [email-masked]
Subject: Re: Liaison from BBF

> inconveniently frequent scenario (impacting ~4% of access nodes at any 

this 4% figure seems *very* high. Can you please provide more details on how you reached that number?

Also, if you have two devices on the same link sharing the same MAC address, you have problems. Period. Having duplicate IP addresses is only one symptom. If you fix that problem, but still have duplicate MAC addresses in use, it is not clear to me that your network will function correctly. Have you done the analysis to be sure that the duplicate MAC address scenario is something that is solvable in practice?

Finally, the charts say you are worried about a "malicious user"
sending out bogus ND packets. ND simply can't deal with this sort of hostile environment, and there is no easy way to fix this. Is that what you are asking this group to fix?

For that matter, ARP doesn't address this problem either. Is there a new problem that shows up with IPv6 that didn't exist with IPv4? And if not, what is wrong with using the IPv4 solutions (assuming they exist)?

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 9 Nov 2009 18:03:29 -0600

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Allan I
>Sent: Tuesday, November 10, 2009 8:00 AM
>To: Manfredi, Albert E; Mikael Abrahamsson
>Cc: [email-masked]

>1) Simple bridging from the home, hence a number of NIC address will
appear at the edge router...

We have so shot down this model in v6ops during the March 2009 IETF -
please see v6ops archives around this date.  If a home router bridges
all traffic from the home then let's say, Apple TV video in the home
will actually to the SP!  Or as Wes said during that time, "I am doing
my private tax returns and the data went to the SP"!

>2) Retail model for RGs, which is how I bought mine... My modem came
from my DSL provider, but as it had no wireless, so I turned off all
higher layer functions and front ended it with a Belkin box >bought over
the counter... 

Yes, this is a very common scenario that we are addressing in the IETF
v6ops IPv6 CE home router. 

Hemant

---

From: David Allan I <[email-masked]>
Date: Mon, 9 Nov 2009 19:13:50 -0500

Hi Hemant:

w.r.t. bridged mode, You folks may have shot it down but is is deployed. And frequently implemented as multiple tagged domains in the home such that not all tags get the same treatment going outside the home....hence there is some containment of the issues you identify....

Simply FYI
D

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, November 10, 2009 9:03 AM
To: David Allan I; Manfredi, Albert E; Mikael Abrahamsson
Cc: [email-masked]; IPv6 Operations
Subject: RE: Liaison from BBF

David Allan I

>1) Simple bridging from the home, hence a number of NIC address will
appear at the edge router...

We have so shot down this model in v6ops during the March 2009 IETF - please see v6ops archives around this date.  If a home router bridges all traffic from the home then let's say, Apple TV video in the home will actually to the SP!  Or as Wes said during that time, "I am doing my private tax returns and the data went to the SP"!

>2) Retail model for RGs, which is how I bought mine... My modem came
from my DSL provider, but as it had no wireless, so I turned off all higher layer functions and front ended it with a Belkin box >bought over the counter... 

Yes, this is a very common scenario that we are addressing in the IETF v6ops IPv6 CE home router. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 9 Nov 2009 18:19:59 -0600

Dave,

If a document can be pointed to that uses the tagged domains, that would
be useful.  I, Wes, and, Ole Troan during the March IETF were talking of
regular bridged networks. Once we see what's going on for data
forwarding in the tagged domain you speak of, we can see what to do
about it.

Thanks,

Hemant

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: Tuesday, November 10, 2009 9:14 AM
To: Hemant Singh (shemant); Manfredi, Albert E; Mikael Abrahamsson
Cc: [email-masked]; IPv6 Operations
Subject: RE: Liaison from BBF

Hi Hemant:

w.r.t. bridged mode, You folks may have shot it down but is is deployed.
And frequently implemented as multiple tagged domains in the home such
that not all tags get the same treatment going outside the home....hence
there is some containment of the issues you identify....

Simply FYI
D

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, November 10, 2009 9:03 AM
To: David Allan I; Manfredi, Albert E; Mikael Abrahamsson
Cc: [email-masked]; IPv6 Operations
Subject: RE: Liaison from BBF

David Allan I

Hemant

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 10 Nov 2009 02:29:59 +0100

I'd like to put forward some additional points which should perhaps be
concise enough to clarify the liaison and questions a bit more. 
There are actually two issues, out of which the duplicate MAC address
issue is IMO a far less tractable problem (as it needs to be solved at
L2 for anything to work).
1. Within a shared L2 domain with constrained forwarding (aka NBMA), for
two users A & B with *different* MAC addresses, user B may spoof the LL
address of user A and thus lead possibly to a DoS attack (on a FCFS
basis). Similarly user B may try to spoof the LL address of N users
(again on an FCFS basis). Does SAVI propose to solve this problem and if
so how?

2. A duplicate MAC address in a shared broadcast domain is a
possibility. 
At L2, this problem is tractable by any one of
a) denying the dupe addresses access to the network service on a FCFS
basis (common practice today)
b) assigning each duped MAC to a different broadcast domain
c) MAC address translation (MAC NAT). 
Solution c) requires some form of ALGs (for v4 and v6). Eg In the v6
case any EUI-64 derived LL addresses will still be the same and thus an
ND ALG appears needed. What is the IETF's opinion about this type of
solution (c), if any?

Regards,
Woj.

> Behalf Of David Allan I
> Sent: 10 November 2009 00:31
> To: Thomas Narten
> Cc: [email-masked]
> Unfortunately having just changed jobs I'm having trouble 
> exactly recreating all my sources of information...
> 
> The following was one anecdotal example offered during our 
> discussions in the spring..."...in a real nationwide telco 
> today with approximately 3.5million DSL ports there is about 
> 300-400 duplicate MAC@ alarms active on the DSLAMs at any 
> time, and this is only where 2 of the same MAC@ appear on the 
> same DSLAM (384-1000 users each)..."
> 
> In a perfect world where all MACs were properly unique and 
> all implementations correctly constructed link local via 
> EUI-64 we'd all be happy campers, it works as intended. 
> Unfortunately that is not the case and we seem to have a 
> hierarchy of grief.....
> 
> 1) Some carriers have deployed MAC address translation in the 
> Access node/DSLAM to ensure MAC uniqueness. This means ALG 
> functionality is required for Ethernet OAM and other 
> protocols, and while fixing MAC uniqueness, does not address 
> duplicates in link local construction unless NAT of the lower 
> 64 bits of LLA is included in the mix.
> 
> 2) Our liaisons with IEEE on the subject and some proposals 
> to the forum focus on the fact that uniquness only needs to 
> exist in a given Ethernet broadcast domain, hence keeping a 
> few extra VLANs in the back pocket to shift duplicate 
> customers to solves the problem, and my math suggested this 
> would inflate VID usage by a corresponding few percent. Issue 
> being this then breaks down if the link local address is not 
> constructed from the MAC, and RFCs have been trotted out at 
> the BBF on NOT using the EUI-64 specifically to defeat 
> traffic analysis attacks. This being an expected deployment 
> scenario when wireless media in the home is considered and an 
> emerging class of FMC capable terminals is deployed. 
> 
> So a solution analogous to DAD appears to be needed, that 
> originates with the edge router, where if the detected 
> duplicate does not subsequently behave in a prescribed manner 
> service may then be denied in the interest of the common 
> good. As DAD is already deployed that would appear to be a 
> path of least resistance vs waiting years for a roll out of a 
> fix. However if my memory serves correctly, unicast from the 
> edge router would be a desirable form and I am unsure if that 
> is supported in standards or implementations...
> 
> Cheers
> D
> 
> 
> 
> 
> 
> Also, if you have two devices on the same link sharing the 
> same MAC address, you have problems. Period. Having duplicate 
> IP addresses is only one symptom. If you fix that problem, 
> but still have duplicate MAC addresses in use, it is not 
> clear to me that your network will function correctly. Have 
> you done the analysis to be sure that the duplicate MAC 
> address scenario is something that is solvable in practice?
> 
> sending out bogus ND packets. ND simply can't deal with this 
> sort of hostile environment, and there is no easy way to fix 
> this. Is that what you are asking this group to fix?
> 
> For that matter, ARP doesn't address this problem either. Is 
> there a new problem that shows up with IPv6 that didn't exist 
> with IPv4? And if not, what is wrong with using the IPv4 
> solutions (assuming they exist)?
> 
> Thomas