Subject: Re: [dhcwg] Default Route configured by DHCPv6?

From: Thomas Narten <[email-masked]>
Date: Mon, 04 Oct 2010 09:16:54 -0400

Alexandru Petrescu <[email-masked]> writes:

> I need a default route configured automatically in the Mobile Router
> connected at home.

See also:

http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00

It's expired, but its on my TODO list to revise and resubmit.

Thomas

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 6 Oct 2010 11:26:28 +0200

Sorry missed this one earlier. Responses in line.

On 16 September 2010 18:08, Alexandru Petrescu <[email-masked]
> wrote:

> Le 13/09/2010 11:04, Wojciech Dec a écrit :
>
>  You may also want to take a look at
>> http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-04 , which
>> is likely to provide what you need.
>>
>
> Thanks this is the kind of option that is interesting (in one way, there
> are others) to me.  In a sense I need the default route delivered to a
> Router via DHCPv6.
>
> I am novice to DHCPv6, thanks for bearing with me.
>
>  When processing a received Route Option a client MUST substitute a
>> 0::0 value of the Next Hop Option with the source IPv6 address of
>> the received DHCPv6 message.
>>
>
> Sounds clear to me, but I am not so clear whether that src address is
> the Server's Address?  Or the Relay's ingress interface address
> (interface on-link with Client's interface)?  Or the Relay's egress
> interface.
>

When setting up a route you would like to know the next hop-address that the
client should use, which may be cumbersome if we're talking about link-local
addresses. The above makes it so that, without knowing the specific next-hop
address at the server, the client will use the link-local address of the
relay, which naturally relayed the response, as the next hop.

>
>  It MUST also associate a Link Local next hop addresses with the
>> interface on which the client received the DHCPv6 message containing
>>  the route option.
>>
>
> I do not understand this MUST?  What does it mean that the Client
> "associates" a link-local address of a next-hop with one of its
> interfaces?  Does it mean insertion of a routing table entry towards a
> next-hop whose address is link-local, entry whose "dev" parameter is an
> interface on which this DHCPv6 message was received?
>

Yes. Link-locals are, well link local in scope. Thus if you get a message
over interface A saying that a next-hop address is a link-local address Z,
the client must take Z to be valid only via A.

>
> Or something else?
>
>  Such a substitution and/or association is useful in cases where the
>> DHCPv6 server operator does not directly know the IPv6 next-hop
>> address, other than knowing it is that of a DHCPv6 relay agent on
>> the client LAN segment.
>>
>
> I am not clear whether the DHCPv6 message arrives from Server to the
> Client (through a Relay) with the src address changed.  That src address
> should be that of the Server.  Architecturally speaking I doubt the
> Relay touches the src address (doubt, no religion), this is clarifying
> question.
>

The DHCPv6 server addresses the packet to the relay. The relay will use its
source ip when passing packets back to the client. A dhcpv6 relay is a
message relay not a packet relay...

>
> I am not clear whether the Server knows at all the link-local address of
> Relay's interface on-link with Client.
>
> It may be possible that the Server does know the global address of the
> Relay's interface on the other side than Client.  But that address is
> useless to the Client (as a next-hop for its default route).
>

Not necessarily. If your client support recursive routing...

>
> Ideally the default route should have next-hop address a link-local
> address - reduce global address waste.
>
>  DHCPv6 Packets relayed to the client are sourced by the relay using
>> this relay's IPv6 address, which could be a link local address.
>>
>
> I am not clear the DHCPv6 packets originated by the Server and dst
> Client are touched by Relay modfiying the src address and I don't see
> why should Relay do so.
>

One reason is that RFC3315 makes the relay a message relay. Another reason
is that to a client, with potentially no global addresses or routes,
returning the global server's ip address will be of little use - the client
still needs to go through the directly attached relay.

Regards,
Woj.

>
> Alex
>
>
>
>> Thanks, Woj.
>>
>> On 12 September 2010 22:40, Alexandru Petrescu
>> <[email-masked] <mailto:[email-masked]>>
>>
>>  wrote:
>>
>> Le 12/09/2010 20:58, Ole Troan a écrit :
>>
>>
>> in this context the upstream or WAN side interface is acting as both.
>> it does some host functions of ND, like acquiring an address and
>> doing router discovery, while forwarding packets as a router. it is
>> not expected that it switched from one "role" to another.
>>
>>
>> Hmm... sounds reasonable to describe it as such.  I optimistically
>> assume all router-vs-host specific aspects in rfc4861 are clear not
>> just some (joining host-vs-router mc groups, sending or not RAs,
>> etc.), on the WAN side interface of CE, the one acting as both host
>> and router.
>>
>> In linux this doesn't work, because if forward==1 then it doesn't
>> acquire a default route with SLAAC (neither a global address); if
>> forward==0 then it does not forward packets.  Or am I overlooking
>> some recent radvd and/or procsys options maybe.
>>
>>
>> you have the source code. fix it. ;-)
>>
>>
>> I'll cycle that forward flag looks easier :-)
>>
>> Just out of curiosity - was it intentional to not configure default
>> routes with DHCPv6?  There's this huge set of configuration
>> parameters in DHCP but no default route...
>>
>> Alex
>>
>> _______________________________________________ dhcwg mailing list
>> [email-masked] <mailto:[email-masked]>
>>
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>
>>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Oct 2010 22:42:32 +0200

Le 04/10/2010 15:16, Thomas Narten a écrit :
> Alexandru Petrescu<[email-masked]>  writes:
>
>> I need a default route configured automatically in the Mobile
>> Router connected at home.
>
> See also:
>

I support the tendency of the ideas in this draft.

It currently lacks a means to encode messages conforming to DHCPv6.  Is
there some initial thought about how shoudl the default route be
communicated in a DHCPv6 message?

When I look at rfc3315, should I dig consider more "IA Address Option"?
  Or more the "Relay Message Option"?  (presumably it's the Relay's
address on which the Solicit was received that should be the default route).

Or is this the wrong way to go.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Oct 2010 23:49:26 +0200

Le 06/10/2010 11:26, Wojciech Dec a écrit :
> On 16 September 2010 18:08, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> When setting up a route you would like to know the next hop-address that
> the client should use, which may be cumbersome if we're talking about
> link-local addresses.

I think we should talk link-local addresses next hop, when discussing
default route, it's not cumbersome. RA does provide a default route next
hop as a link-local address (rfc4861 RA src MUST be link local and
lifetime non-zero).

> The above makes it so that, without knowing the
> specific next-hop address at the server, the client will use the
> link-local address of the relay, which naturally relayed the response,
> as the next hop.

Sounds interesting. (but it's different than DHCPv4 where the address of
the default route is in the configuration file at Server, not
necessarily the one of the Relay interface to Client.)

> Yes.

It would read better to me if it said insertion of a routing table
entry, rather than "associates".

The "association" is between 3 things: a "::", an "interface" and a Next
Hop address. IMHO. Your association seems to be only between a Next Hop
address and an interface, not "::".

> Link-locals are, well link local in scope. Thus if you get a
> message over interface A saying that a next-hop address is a link-local
> address Z, the client must take Z to be valid only via A.

Yes, and additionally for "::".

>         address, other than knowing it is that of a DHCPv6 relay agent on

Shoudl DHCPv6 Server configuration file work like the DHCPv4 Server
configuration file, where the Server does know this IPv6 next-hop
address, based on the "subnet".

> The DHCPv6 server addresses the packet to the relay. The relay will use
> its source ip when passing packets back to the client. A dhcpv6 relay is
> a message relay not a packet relay...

I see now about the relayed. It saves me checking the packet dumps, thanks.

>     useless to the Client (as a next-hop for its default route).

For DHCPv4 the Server also knows the default route, as the next-hop
("option routers").

> Not necessarily. If your client support recursive routing...

Recursive routing...

>         this relay's IPv6 address, which could be a link local address.

It think it should not could.

> One reason is that RFC3315 makes the relay a message relay. Another
> reason is that to a client, with potentially no global addresses or
> routes, returning the global server's ip address will be of little use -
> the client still needs to go through the directly attached relay.

I agree.

Alex

>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>           wrote:
>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>