RA for a different router

[Marco Hogewoning]

>> Why wouild you want anything else then a link-local on the WAN
>> interface ?
> 
> Good question, I agree. But, it was useful in the ipv4 past,
> and I assume it will be useful in the v6 future.

I think it depends on perspective there, did you or did you not have an IPv4 address on the WAN side when using a regular residential setup using a single IP and NAT. Does it really belong to the WAN interface is or it some 'virtual', almost quantum like behavior where it only is there when you look for it.

>> It works perfectly well without any GUA
> 
> I can't test it from the monitoring host, which is not on the local link.

I have this running with multiple IOS versions, AVM's FRITZ!box and some beta's from vendors who do not whish to be disclosded at this point in time, I must add we use Juniper E-series (9.2.x) as edge routers on our end. We only use DHCPv6-PD at this point in time and it works perfectly, CPE negotiates IPv6CP and after establishing a link-local fires of DHCPv6 on which it will only get an IA_PD.

>> and all you do
>> by assigning one is create another point to secure
> 
> I have to secure it if it is link-local or GUA, anyway.

That was too short, let me explain :)

(please note that when it comes to IPv6 size does matter and I'm not talking about those 96 bits)

There are multiple ways on handling this:

1)	Use SLAAC on the wan interface, this can be done 2 ways:
	1a)	seperate /64 per PPP interface
	1b)	use one /64 for multiple customers
2)	Use DHCPv6 and assign IA_NA

We never pushed the limit on it, but considering option 1a you have a lot of stuff to keep track of. Each /64 requires an entry in the forwarding table and you need to keep track of a couple of counters, this might be a working setup when running a couple of hundred customers, but what if you run boxes with 40k connections ? Although RA is multicast you have to build seperate packeta for each individual link which can and will eat a lot resources.

Option 1b saves you a lot of trouble in the sense you can truly multicast and modern hardware should not be bothered to much by it, however you still need a lot of entries in your forwarding and neighbor tables which are redundant. This is also the point where security comes around the corner, how do you keep track of which user uses which address (and at which point in time). Now you might already have a database of mac-addresses, but how to secure your network from spoofing ? And keep in mind we are talking GUA here, what would happen if I would manage to assign that address to a more intelligent form of hardware like my workstation, it would not take much to come up with a lot of addresses to do evil from (spam/virusses). Source address verification and uRPF will work sort of but since it's supposed to be stateless a DAD should be enough to secure an address and have it forwarded.

This is of course fixable by putting up some ACLs on your side of the network to limit those addresses to certain protocols (ICMPv6) but this does mean extra overhead in managing the network and yes, if your network is only a few boxes and a couple of hundred customers this is not a problem, if you try an attempt at world dominination and you reach the million mark this all of sudden can be quite a headache and possibly requires  a substantial investment in patches on management software.

Option 2 will at least mean you have a trace on who-is-who and with a bit of luck your $vendor allows to control SA-validate by DHCP taking away the risk of spoofing. What is left again is a lot of extra and theoretically redudant slots in the forwarding table and another 'thing' to manage which might look easy when you're not that big.

One final point to keep in mind from an operator perspective are goverment regulations regarding data retention and lawfull intercept, by assiging additional addresses you might be forced to also register and keep additional data and suffer the cost and pain that comes with it.

The only workaround we came up with when discussing wether we should go for GUA on the WAN was to assign the wan address in a subnet which was part of the IA_PD assigned to this customer, this takes away a lot of the track-and-trace issues but the question of scalabillity stays around.

And yes to answer your question, you have to secure the modem anyway and as far as the simple-security draft is properly implemented it shouldn't be an issue, but than again we are better safe then sorry and sufficient limited scope can take away a hell of a lot possible issues.

>> and a second address pool to manage.
> 
> Yes, but we do this all the time, it's not a big problem.
> 
>> ICMP can be sourced from a 'virtual interface'
>> and that is what all CPE I tested so far do, the current IETF drafts
>> cater for this, it's covered for by WAA-6/WPD-5 in
>> draft-ietf-v6ops-ipv6-cpe-router-03.
> 
> As soon as someone does firewalling on all his LAN prefixes with his
> CPE, I'd like to have a seperate IP to test 8-)

As soon as somebody starts firewalling he most likely also starts messing with the WAN address. It is largely implementation dependend where the ACL is placed logically....do you drop at the outside or control it when it goes out onto the LAN.

So far we have been asking vendors to pick a 'well known' address (like ::1) and at least make sure it responds to ICMPv6 echo, preferably this will be hardcoded in the firmware, but at least it should be the factory default to not mess with ICMP. 

> I have one such case right now in the v4 world, where the
> customer insists that he's not probed from our monitoring, but
> complains if the link is missing 8-) Beautiful 8-)

Yeah, somebody should come up with a standard for customers themselves.

> Yes, yes, check link state or interface counters instead, all this
> is possible, but it's not as nice as just sending a ping 8-)

You are talking ping for monitoring, go residential and all of a sudden you don't care about ICMP but you are actually running real management to push out configs and firmware updares (TR69) so you need to be able to actually access the modem.

>> I notice this requirement popping everytime and nobody can tell
>> me what the need is.
> 
> Since when is "Because I want to!" together with foot-stomping not
> reason enough 8-) ?


Well apparently it is enough because I keep explaining to vendors why we don't want a routable address on the outside and how the IETF draft we asked them to follow actually allows for it.

MarcoH