Subject: Re: IPv6 broadband provisioning

From: Mark Smith <[email-masked]>
Date: Tue, 1 Jan 2008 16:00:23 +1030

On Mon, 31 Dec 2007 12:49:34 +0100
Iljitsch van Beijnum <[email-masked]> wrote:

> On 31 dec 2007, at 8:22, Mohacsi Janos wrote:
> 

<snip>

> On 30 dec 2007, at 11:33, Mark Smith wrote:
> 
> >> The issue that I see is that of duplicate MAC addresses. I don't see
> >> an easy way to protect against that. How does this work today in a  
> >> N:1
> >> model?
> 
> > The DSLAMs we use perform MAC address - wait for it - NAT, into
> > algorithmically calculated MAC addresses, in part based on line card
> > and node IDs.
> 
> Which of course creates all the usual problems that NAT always  
> creates: what about protocols that embed the translated addresses? In  
> this case, that would be neighbor discovery.
> 

Good point. That puts us between a rock and hard place. It's something
we'd want to leave enabled to avoid the effects of MAC address
collisions, accidental or intentional, but it would probably interfere
with the operation of ND/RAs and possibly DHCPv6. I might start looking
into that a bit more, and when I get back to work on Thursday, discuss
it with our DSLAM expert. We're only using that feature for PPPoE
connections at the moment, and that's obviously working, so I'd presume
PPPoE doesn't carry any MAC address info in the payload.

> > It's ugly thinking about all the FCSes that are being
> > recalculated all the time
> 
> That happens in the ethernet hardware, not an issue.
> 

I think it's ugly for a couple of reasons - the reason you mention
above, and also that the FCS isn't being preserved from the ultimate
source to the ultimate destination node, which creates the opportunity
for corruption to be introduced during the FCS recalculation.
Admittedly 802.1q does the same thing, so it's probably an acceptable
risk (ISL would have been better for the IEEE to adopt if the hardware
out there had been able to cope with it as the trunked or rather
tunnelled frame isn't modified).

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 Jan 2008 18:21:07 +0100 (CET)

On Sat, 29 Dec 2007, David Miles wrote:

> I'm not sure we need to use global-unicast addresses on the WAN CPE interface

I would strongly suggest that customer is not allowed to source packets 
outside if his/her assigned IP space. So if link-local can be used for all 
packets (when customer has a router), we get a very nice demarcation and 
can do filtering where we know that our infrastructure is in a certain 
IPv6 range and customers are in another, and we know none of our equipment 
is in customer space and vice versa.

So if possible, assign and route the /56 or /48 to the customer router and 
this router then needs to make sure it uses its internal IP to source 
packets destined for global Internet.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Thu, 3 Jan 2008 05:14:51 +1030

On Wed, 2 Jan 2008 18:21:07 +0100 (CET)

> packets destined for global Internet.

Maybe I'm missing something really obvious, but how are operators and
their helpdesks going to be able to troubleshoot customer connectivity
problems via offlink ping or traceroute if the link between the
customer and the upstream infrastructure only has link locals? PMTUD
won't work either in certain scenarios due to RPF filtering or
non-forwarding of LL sourced traffic. I wouldn't be all that
comfortable having front line techsupport staff logging into customer
facing aggregation routers for basic troubleshooting, even if it was
into a non-priviledged account.

It's also common for CPE to run a caching DNS servers and NTP
peers these days, which the downstream devices can use, so they'd break
too.

I understand the motive for the suggestion, however I don't really see
how it couldn't be more trouble than it's worth. A ULA prefix on that
upstream link would address some of the issues, but not all of them.
I think to provide global Internet access you really need to ensure a
fully globally addressed path to and from the Internet.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 Jan 2008 19:51:58 +0100 (CET)

> peers these days, which the downstream devices can use, so they'd break

No, the CPE would use a loopback address for sourcing packets destined to 
the outside (or it's LAN adress).

> fully globally addressed path to and from the Internet.

So you think that "ip unnumbered loopback0" in IPv4 is really weird to 
have on WAN interface? It's basically the same thing.

---

From: David Miles <[email-masked]>
Date: Thu, 3 Jan 2008 09:00:44 +1100

Mark,

As Mikael said, ICMPv6 messages would not be sourced from link-local  
addresses if the destination IP was a global unicast address, but the  
question of what address they do use would be up to implementation.  
Agreed there is a need for device management such as DSLForum TR-69  
and as you point out, we need an address for sourcing DNS, NTP, etc.  
Options that have been discussed with some of my peers include:
- Using a small network from the delegated prefix for purposes of  
network management (the loopback that Mikael suggest). For example:
	Delegated 2001:db8::/56
	Device uses 2001:db8::/64 for "management functions"- with  
2001:db8::0 as the interface/loopback IP address
	2001:db8:0:1::/64 for LAN interface

Concerns with this approach is that you depend on the CPE to decide  
what prefix to use - and then there is the "dedication" of a whole ::/ 
64 to the job (if that is a concern to others). For ICMP it should be  
up to the CPE to decide what address to respond from, but for ISP  
management and TR-69, it would be nice to know in advance what IP is  
"listening" (though TR-69 would not require this as it has the concept  
of device registration).

- Approach 2, use the LAN IPv6 address for management. The issue here  
is interface state. Ie, if WAN interface is up, but LAN interface is  
down then this is a bad situation.

Unfortunately devices like edge routers, BRAS, BNG and CMTS do have  
finite resources. While it may seem inconsequential to have two  
prefixes assigned to a customer for anti-spoofing entries, routes,  
accounting and classification - it really could add up! Today, most  
broadband customers are represented by a single /32. During IPv6- 
transition, we need to add another prefix so now we have two per  
subscriber. Do we want to go to three (ie, a IPv4 /32, the "WAN" ::/ 
128 and a ::/56)? Note that link-local does not need to be used for  
anti-spoofing, accounting and classification as no customer-sourced  
traffic (except DHCP and BNG-initiated ICMP) would use this src  
address, nor would it go anywhere.

I understand there has been operational experience with such a model  
per RFC 4241 but I have not had personal experience with it in IPv6,  
or the equivalent of the CPE WAN being IP(v4) unnumbered for broadband  
subscribers.
In my experience the use of ICMP ping is not a reliable way of doing  
first-mile assurance and hence it the ATM world we used ATM OAM F4/F5,  
in Ethernet we use IEEE 802.3ah/802.1ag. The operational issue with an  
IP-level analysis is that there is a lot of non-IP equipment between  
subscriber IP interface and ISP IP interface.

By the way, I think the option should be there but I'd like to work  
through the alternative to understand the issues.

-d

On 03/01/2008, at 5:51 AM, Mikael Abrahamsson wrote:

> No, the CPE would use a loopback address for sourcing packets  
> destined to the outside (or it's LAN adress).
>
> So you think that "ip unnumbered loopback0" in IPv4 is really weird  
> to have on WAN interface? It's basically the same thing.
>
> --

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 2 Jan 2008 23:34:00 +0100

On 2 jan 2008, at 19:44, Mark Smith wrote:

> customer and the upstream infrastructure only has link locals?

When a packet is to be generated and sent out on a link local  
addressed interface towards a non link local destination, a source  
address is borrowed from another interface without explicitly  
configuring "ipv6 unnumbered" (although Cisco IOS will let you do  
that, too).

> PMTUD
> won't work either

Hm, yes, if the LAN behind the CPE uses smaller packets than the WAN  
link to the ISP. (Which is actually true for my DSL line, which has a  
4470 byte ATM MTU but both my router and my ISP's only support 1500 on  
the LAN side.)

> A ULA prefix on that
> upstream link would address some of the issues

No, that would break pretty much all the stuff you mentioned without  
the automatic borrowing of a global address.

> fully globally addressed path to and from the Internet.

If you do DHCPv6 prefix delegation it seems a bit much to also assign  
an address. But if you have RAs anyway to support the case where the  
CPE bridges rather than routes, you get the global address for free.

Iljitsch

---

From: Mark Smith <[email-masked]>
Date: Thu, 3 Jan 2008 19:47:28 +1030

On Wed, 2 Jan 2008 19:51:58 +0100 (CET)

> have on WAN interface? It's basically the same thing.

Hmm, I've been influenced by my environment.

My environment is a Ethernet / DSL environment. I've been imagining
deploying IPv6 in the N:1 model that's been mentioned earlier, so all
CPE WAN interfaces within e.g. an exchange, are all sitting as nodes on
the same /64. The N:1 model is attractive of course because at a
minimum it avoids all the (pseudo in the case of ethernet) point to
point "WAN" links, and the question of whether to assign global /64s to
the them or not .. the question that's being asked :-) 

Regards,
Mark.

---

From: Alastair Johnson <[email-masked]>
Date: Thu, 03 Jan 2008 23:41:58 +1100

> the them or not .. the question that's being asked :-) 

The concept still applies for N:1.  The (pseudo) links in a N:1 
environment are still there, with link-local addresses.  The RG still 
uses a loopback (or LAN) global scope address for global scope traffic.

There are some gotchas with DAD in a split-horizon environment like this 
though...

David Miles can explain more around this - he's been looking at it in 
detail.

aj.