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

[Arifumi Matsumoto <[e-mail]>]

Hi, Mikael, Hemant,

I think Mikael's concern is fair and it should be addressed clearer in this document.

I agree that this rule is applicable when
- SLAAC is used for address assignment.
, or
- DHCPv6 server/relay is used for address assignment and it's on the router sending RA.

Also, I understand DHCPv6 client is often in userland, so it's not trivial to implement it.

So, the description of this rule should be like:

If the implementation can know and manage the coupling of a next-hop and a prefix
delegated from it, then the corresponding prefix should be chosen as the source address.
For example, in SLAAC case, ... (the description of how the coupling is acquired and used)

Regarding whether this new rule should be included in 3484bis,
I know some rules in RFC 3484 is implementation dependent. 
For example,  the destination address selection rule 1: "avoid unusable destinations"
is implemented in several ways.
So, I do not think implementation dependent rule is always bad.
The point should be how much benefits we see in this proposed rule.

Best regards,

On 2011/03/28, at 21:36, Mikael Abrahamsson wrote:

> On Mon, 28 Mar 2011, Brian Haberman wrote:
> 
>> Hi Mikael,
>> 
>> On 3/28/11 4:25 AM, Mikael Abrahamsson wrote:
>>> 
>>> Hello.
>>> 
>>> I read through 2.3 of the draft, and I am a bit unclear as to how the
>>> next-hop should be selected.
>>> 
>>> In the case of my SLAAC machine, I see the next-hop for my default-route
>>> as a LL address. How would the SA and the default router LL be tied
>>> together?
>> 
>> One way would be for the stack to keep track of which router's LL
>> address was the source of the PIO containing the prefix used to generate
>> the address.
> 
> I realise this is a possibility, but shouldn't there be a mention in the draft of recommended mechanisms to achieve this goal?
> 
>>> In the case of getting address using DHCPv6, there is also no direct
>>> connection between the default route and the SA, as the DHCPv6 server
>>> might be different from the default-route gw?
>> 
>> Does the DHCPv6 response contain any information about the DHCP-relay used?
> 
> If the DHCPv6 server is just local to the network and doesn't use a relay?
> 
> Afaik there has been a deliberate decoupling of stateful DHCPv6 and SLAAC so as to make DHCPv6 not able to hand out a default routes, so I don't really see how this coupling can be done again with the basic mechanisms available today?
> 
> In v6ops I was pointed to BRDP <http://tools.ietf.org/html/draft-boot-brdp-based-routing-00> which is an expired draft, I believe a mechanism like this is needed to properly achieve the goal of correct default route for certain SA. I don't really see how it can be done otherwise.
> 
> -- 
> Mikael Abrahamsson    email: [e-mail]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------