RE: question regarding draft-ietf-6man-rfc3484-revise-02 section 2.3

[Mikael Abrahamsson <[e-mail]>]

On Mon, 28 Mar 2011, Hemant Singh (shemant) wrote:

> Here is an attempt to explain the text above from section 2.3 of the 
> document that I have included between squared brackets above.  SA was 
> acquired using DHCPv6 where the DHCPv6 response did arrive to the client 
> on the IPv6 link-local address of the first-hop.  The client already 
> knows this link-local address matches a mac-address of, say, 
> mac-address1 obtained from the RA from the same first-hop router.  Thus 
> SA is associated with Router 1 (from Figure 1 of section 2.1.1 of RFC 
> 5220).  Likewise SB is associated with Router 2 with mac-addr of say, 
> mac-address2.  Thus far we established that SA is used when sending to 
> the default router of Router 1 and likewise for SB with Router 2.  An 
> orthogonal question is how does the host know for a destination D which 
> default router to go to - should such a question be addressed by this 
> document?  If yes, then an out of band mechanism is needed to let the 
> host know what default router to use for a destination D.  One out of 
> band mechanism is use an MSR to signal a specific route to the host.
>
> Did I miss anything?

I am not at all worried about "destination D". Destination based routing 
we know how to do already, we can always add an IGP.

Source based routing is more magic.

Your above text is approximately what I envisioned how things could work, 
and I do think there needs to be text somewhere that describes this. I am 
though worried that it would require quite a lot of work to implement this 
because of the decoupling between DHCPv6 and routing as I mentioned 
before, since for instance on Linux the kernel handles RA and DHCP client 
runs in userspace. They will need to invent new APIs or move things around 
to handle what we're requiring here.

Anyhow, the above text seems fine to me from a technical point of view, 
nothing pops up as weird or wrong anyway. I think it needs a second look 
over before it's ready for publishing?

-- 
Mikael Abrahamsson    email: [e-mail]