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

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 28 Mar 2011 10:25:08 +0200 (CEST)

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?

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?

There is a use of "destination D" in several places, for a default-route 
this seems misplaced and has caused misunderstandings recent discussions 
in v6ops, perhaps there would be benefit in using different terminology 
here?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Mon, 28 Mar 2011 08:22:15 -0400

Hi Mikael,

> as a LL address. How would the SA and the default router LL be tied

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.

> might be different from the default-route gw?

Does the DHCPv6 response contain any information about the DHCP-relay used?

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Mar 2011 07:36:16 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mikael Abrahamsson
Sent: Monday, March 28, 2011 10:25 AM
To: [email-masked]
Subject: question regarding draft-ietf-6man-rfc3484-revise-02 section
2.3

Mikael,

>might be different from the default-route gw?

It's the IPv6 default router for the DHCPv6 client that sends a RA with
the M-bit set and seeing such an RA the client initiates DHCPv6.  Or the
client could initiate DHCPv6 even on receiving an RA with the M-bit
cleared.  But the fact still remains that the DHCPv6 client did receive
an RA from the IPv6 first-hop router to the client.  The client is
supposed to perform router discovery and send RS.  The RA lets the
client know what the default router is.  If I missed anything, perhaps
if you could please draw a diagram and let us know what specific use
case I missed.

Thanks,

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 28 Mar 2011 14:36:51 +0200 (CEST)

> address was the source of the PIO containing the prefix used to generate

I realise this is a possibility, but shouldn't there be a mention in the 
draft of recommended mechanisms to achieve this goal?

> 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.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 28 Mar 2011 15:04:02 +0200 (CEST)

> if you could please draw a diagram and let us know what specific use 

I'm thinking in the terms of multiple routers on the same LAN but with 
multiple subnets, the multihoming scenario we're discussing in v6ops.

Your above description makes perfect sense for single homing, and if text 
like this (how to tie them together) was present in the draft (or a 
referral to other text describing it), I'd be fine.

Right now I couldn't help reading the text in section 2.3 and wondering 
how it was supposed to achieve what was described.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Mar 2011 08:08:26 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Monday, March 28, 2011 2:22 PM
To: [email-masked]
Subject: Re: question regarding draft-ietf-6man-rfc3484-revise-02
section 2.3

>Does the DHCPv6 response contain any information about the DHCP-relay
used?

No - the reason is because the relay strips the relay-reply from the
server and then sends the response to the client's IPv6 link-local
address.  I am assuming the goal of this discussion is to find out how
does the client gets its default route?  The first-hop router also
happens to be a DHCPv6 relay agent. The email that I just sent will be
able to let the client know what the mac-address of the default router
is.  Thus when the client sends a globally destined packet upstream
towards the default router, the packet has a global destination and
global source (the source global address was acquired from DHCPv6).  The
packet is shipped to the default router using the mac-address of the
first-hop default router. 

My humble apologies if I did not understand the question being asked.
If that is the case, please articulate which node or policy table needs
to decide what for a SA and then we can discuss more.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Mar 2011 08:13:38 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Monday, March 28, 2011 3:04 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: question regarding draft-ietf-6man-rfc3484-revise-02
section 2.3

>multiple subnets, the multihoming scenario we're discussing in v6ops.

Ah, thanks for this clarification.  No I understand the problem at hand.
Sorry, I haven't read the document being discussed here.  Let me started
from the section 2.3 of this document and then also mull over the
multihoming issue.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Mar 2011 09:28:55 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Monday, March 28, 2011 3:04 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: question regarding draft-ietf-6man-rfc3484-revise-02
section 2.3

Mikael,

>how it was supposed to achieve what was described.

[If SA is assigned by the selected next-hop that will be used to send to
D and SB is assigned by a different next-hop, then prefer SA.
Similarly, if SB is assigned by the next-hop that will be used to send
to D and SA is assigned by a different next-hop, then prefer SB.]

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?

Thanks,

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 28 Mar 2011 18:01:28 +0200 (CEST)

> band mechanism is use an MSR to signal a specific route to the host.

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?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Mar 2011 11:39:53 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Monday, March 28, 2011 6:01 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: question regarding draft-ietf-6man-rfc3484-revise-02
section 2.3

>over before it's ready for publishing?

Ah, the text I wrote is in conversational language and I don't deem the
text for use in an RFC.  However, if the WG thinks such text needs
addition to this document, I'd be happy to provide more tighter text.
For example, change mac-addr to link-layer address and the fact that if
the link layer supports addresses, it is the IPv6 ND Source Link-Layer
Address option that carries the link-layer address.

Hemant

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 30 Mar 2011 00:15:03 +0900

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:

> I realise this is a possibility, but shouldn't there be a mention in the draft of recommended mechanisms to achieve this goal?
> 
> 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.
> 
> -- 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Philip Homburg <[email-masked]>
Date: Wed, 30 Mar 2011 17:49:05 +0200

>For example, in SLAAC case, ... (the description of how the coupling is acquir

I think this is fine as an optimization, but do we really want to force hosts
to be involved in routing packets?

So far, the model is that a host can just dump a packet at a default router
and the router will figure it out.

In more complex setups, i.e. where there are multiple CPEs providing access
to different ISPs but also multiple internal LANs at the site, routers will
have to know the right exit for a packet anyhow.

So I would propose to focus on (and put emphasis on) getting routers to 
send packets to the right ISP and only add changes to the hosts as an
optimization.