Re: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04

["Konrad Rosenbaum" <konrad@silmor.de>]

Hi,

On Wed, April 28, 2010 08:47, Wojciech Dec wrote:
> Updating RFC4861 is not the intent and there is no modification of the
> protocol being proposed here. Citing from the begging of this thread:
>
> RFC4861 states:
> " A host sends Router Solicitations to the all-routers multicast
>    address.  The IP source address is set to either one of the
>    interface's unicast addresses or the unspecified address."
>
> As such having Rses with a unicast address is already covered by the
> protocol. The proposed change tightens the CPE's RS sending rule, which
> combined with serialized DAD (or even optimistic DAD), makes sense.

From a programmers perspective I do not think that it would be realistic
to tighten this specific requirement and expect people to comply. There
aren't many router vendors out there who write the entire software stack
of their routers - this is especially true for (relatively cheap) CPE
equipment.

The RS/RA and DAD protocols are usually implemented deep inside the
operating system kernel. I can't even find an option for Linux to switch
between RA with LL and null source address.

So in order to make sure I comply with such a requirement I would have to
dig deep into the kernel source and probably change it, while I would
already be under a very tight schedule fighting against my hardware
platform vendors development kit.

Right now is one of the very few moments that I'm happy I don't work for a
CPE router manufacturer. ;-)

On a related note: I would expect ISP side equipment to work with most
common systems out there without forcing significant or unintuitive
changes on them. In this particular case: find a way to inspect the MAC
address or line-ID instead of relying on the LL source address of the RA
message.


    Konrad