Subject: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 12 Sep 2011 10:40:56 +0530

Hi,

I read this draft, I think similar issue is also being discussed/solved
by draft-dec-dhcpv6-route-option-05 as well.

I see that you are proposing to have lifetime and MAC address in the
route option. Why do we want to communicate the lifetime of the route in
this option and that too I guess you are proposing to have a upper limit
of 150 minutes (9000 seconds) on that. What is the reason behind that.
What should be done after the expiry of this 150 minutes..?
Information-Request..? or DHCP Renew.?

I don't think that router lifetime will be that short and even if router
lifetime expires, DHCPv6 server can just send RECONFIGURE.  Normally
IPv6 addres lease time will not usually be that less.  

Further, What's the real need of having MAC/link address in the route
list option as there already exists means to get it.

Thanks,

Gaurav

---

From: maximilien mouton <[email-masked]>
Date: Mon, 12 Sep 2011 23:32:34 +0200

Hi Gaurav,

Thank you for your review. See my answers inside.

> by draft-dec-dhcpv6-route-option-05 as well.

Can you say more about this discussion?

> of 150 minutes (9000 seconds) on that. What is the reason behind that.

Actually we are following section 6.2.1 of rfc 4861 but this value can
be discussed.

> Information-Request..? or DHCP Renew.?

I tend to Information-Request.

>
> I don't think that router lifetime will be that short

I understand your comment. What do you propose? 7 days like proposed for 
a not default route?
Do you think this field should be 2 or 4 bytes long?

> and even if router
> lifetime expires, DHCPv6 server can just send RECONFIGURE.

I agree.

> Normally

We assume that this option is useful because it gives the client the 
possibility to avoid waiting for na.

Thanks,

Maximilien

>
> Thanks,
>
> Gaurav
>
>
>
>
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Sep 2011 13:20:02 +1200

> Le 12/09/2011 07:10, Gaurav Halwasia (ghalwasi) a écrit :

...
>> lifetime expires, DHCPv6 server can just send RECONFIGURE.

However, that has to be sent unicast to every DHCP client.
That makes it problematic for a large network.

    Brian

---

From: maximilien mouton <[email-masked]>
Date: Tue, 13 Sep 2011 06:40:08 +0200

Hi Brian,

My answer below.

> That makes it problematic for a large network.

In this case an Information-Request when client's lifetime expires (or
is close to) is sufficient especially if lifetime's upper limit is
higher.

Thanks

Maximilien

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Tue, 13 Sep 2011 11:18:14 +0530

Hi Maximilien,

>Can you say more about this discussion?

Draft [draft-dec-dhcpv6-route-option-05] handles the cases of both default/other static route using one generic option. That's it I was able to gather in my one glance to this draft.

On Route lifetime and the length of it's field.
I strongly think that this field is unnecessary as I don't think default route (given by DHCPv6 server) will be that shortlived. Even if it is short lived, anyways a new message exchange needs to happen irrespective of this field. (either server initiated or client initiated.)

In ND, as the messages are quite periodic (in comparison to DHCPv6), having a lifetime in ND message makes sense. One of the primary use of having lifetime in ND is to advertise route as stale (by setting lifetime as zero).

The main purpose of having RECONFIGURE (sent by Server) message is to actually achieve the same thing. At the first place, I feel that default routes are not going to be that short lived and even if it is (in some scenarios), server can always use RECONFIGURE.

On MAC address issue.
Again, think that it's not a good idea to send MAC address of default router in DHCPv6 option. I will probably eat a lot of bandwidth in comparison to the benefit it can provide.

Thanks,
Gaurav

-----Original Message-----
From: maximilien mouton [mailto:[email-masked]] 
Sent: Tuesday, September 13, 2011 3:03 AM
To: Gaurav Halwasia (ghalwasi)
Cc: [email-masked]
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

Hi Gaurav,

I agree.

Thanks,

Maximilien

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 13:01:39 +0000

On Sep 13, 2011, at 12:40 AM, maximilien mouton wrote:
In this case an Information-Request when client's lifetime expires (or
is close to) is sufficient especially if lifetime's upper limit is
higher.

One thing to be crystal clear about is that even if an option is added that contains a lifetime, it would be a major extension of the DHCP protocol to propose that the client include that lifetime in its calculations for when to renew.   Adding an option is a minor extension.   I would oppose a major extension for this purpose; I don't know how the working group as a whole would feel about it, but I suspect there would be a great deal of skepticism.

The way lifetimes of configuration information are handled is either with the IRT, in the case of stateless DHCPv6, or with the lease renewal timer, in the case of stateful.   So if you put a lifetime in a route option, I don't see what good it would do.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 18:18:36 +0200

Le 13/09/2011 15:01, Ted Lemon a écrit :
>> In this case an Information-Request when client's lifetime expires
>> (or is close to) is sufficient especially if lifetime's upper limit
>> is higher.
>
> One thing to be crystal clear about is that even if an option is
> added that contains a lifetime, it would be a major extension of the
> DHCP protocol to propose that the client include that lifetime in its
>  calculations for when to renew. Adding an option is a minor
> extension. I would oppose a major extension for this purpose; I don't
> know how the working group as a whole would feel about it, but I
> suspect there would be a great deal of skepticism.
>
> The way lifetimes of configuration information are handled is either
>  with the IRT, in the case of stateless DHCPv6, or with the lease
> renewal timer, in the case of stateful. So if you put a lifetime in a
> route option, I don't see what good it would do.

I agree DHCP has its separate means to deal with lifetimes.

Default route (not route in general) has a particular lifetime
characteristic when managed with ND.

It is good that lifetime of ND and of DHCP are coherent when used on
default route.

Alex

>
>
>
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 18:35:31 +0200

Le 13/09/2011 07:48, Gaurav Halwasia (ghalwasi) a écrit :
> Hi Maximilien,
>
>>> I read this draft, I think similar issue is also being
>>> discussed/solved by draft-dec-dhcpv6-route-option-05 as well.
>>>
>
> Draft [draft-dec-dhcpv6-route-option-05] handles the cases of both
> default/other static route using one generic option. That's it I was
>  able to gather in my one glance to this draft.

Clarification: do you actually mean
draft-ietf-mif-dhcpv6-route-option-03 (which is a WG item) instead of
draft-dec-dhcpv6-route-option-05?

> On Route lifetime and the length of it's field. I strongly think that
> this field is unnecessary as I don't think default route (given by
> DHCPv6 server) will be that shortlived. Even if it is short lived,
> anyways a new message exchange needs to happen irrespective of this
> field. (either server initiated or client initiated.)
>
> In ND, as the messages are quite periodic (in comparison to DHCPv6),

PEriodicity of ND messages can be tweaked at knob.

Also, DHCP can be quite verbose.

In a WiFi hotspot setting of several APs I see DHCP messages as often as
every minute, or worse - depends on user physical speed - which is
unpredictable.  The quicker the movement, the more often DHCP messages
happen.

> having a lifetime in ND message makes sense. One of the primary use
> of having lifetime in ND is to advertise route as stale (by setting
> lifetime as zero).

Hmm.. yes and no.

Yes prefixes in ND structures may become stale in time, or triggered.

No, thinking the "Router Lifetime" (not "route lifetime") set to 0 in an
RA means that is a default router, and does not mean that is a stale route.

> The main purpose of having RECONFIGURE (sent by Server) message is to
> actually achieve the same thing. At the first place, I feel that
> default routes are not going to be that short lived and even if it is
> (in some scenarios), server can always use RECONFIGURE.

I agree there are a number of choices of what happens when lifetime of a
default route expires.  We have not implemented this because we don't
know for sure what should happen.

> On MAC address issue. Again, think that it's not a good idea to send
>  MAC address of default router in DHCPv6 option. I will probably eat
> a lot of bandwidth in comparison to the benefit it can provide.

The benefit of having (optional) MAC address in the DHCP Advertise next
to the IP address of the default router is that it avoids doing NS-NA to
solve that IP address into a MAC address.

MAC address is 48bit and a pair of NS-NA messages is bigger in terms of
message size.

Alex

> Thanks, Gaurav
>
> -----Original Message----- From: maximilien mouton
> [mailto:[email-masked]] Sent: Tuesday, September 13,
> 2011 3:03 AM To: Gaurav Halwasia (ghalwasi) Cc: [email-masked] Subject:
> Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
>
> Hi Gaurav,
>
>> I read this draft, I think similar issue is also being
>> discussed/solved by draft-dec-dhcpv6-route-option-05 as well.
>>
>
>> I see that you are proposing to have lifetime and MAC address in
>> the route option. Why do we want to communicate the lifetime of the
>> route in this option and that too I guess you are proposing to have
>> a upper limit of 150 minutes (9000 seconds) on that. What is the
>> reason behind that.
>
> Actually we are following section 6.2.1 of rfc 4861 but this value
> can be discussed.
>
> I understand your comment. What do you propose? 7 days like proposed
>  for a not default route? Do you think this field should be 2 or 4
> bytes long?
>
>
>> and even if router lifetime expires, DHCPv6 server can just send
>> RECONFIGURE.
>
> I agree.
>
>> Normally IPv6 addres lease time will not usually be that less.
>>
>>
>>
>> Further, What's the real need of having MAC/link address in the
>> route list option as there already exists means to get it.
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 16:58:58 +0000

On Sep 13, 2011, at 12:18 PM, Alexandru Petrescu wrote:
It is good that lifetime of ND and of DHCP are coherent when used on
default route.

Could you restate your point more explicitly?   I find that I could interpret your response to mean either that you think that the major extension to DHCP is required, or that it is not.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 19:26:23 +0200

Le 13/09/2011 18:58, Ted Lemon a écrit :
>> It is good that lifetime of ND and of DHCP are coherent when used
>> on default route.
>
> Could you restate your point more explicitly? I find that I could
> interpret your response to mean either that you think that the major
>  extension to DHCP is required, or that it is not.

Allow me explain myself.

I am not sure what is meant by a major extension to DHCP.  Generally
speaking I oppose major rehauling of such vast software as DHCP
benefitting such huge installed base.

But I do believe a different option type is needed to communicate the
default route (different than the option type used in general for route
option for DHCP).

In the particular case of default route being communicated by DHCP (not
generally any routes communicated by DHCP) I believe that DHCP should
use a lifetime for default route in a way that is coherent with how ND
communicates that default route.

The lifetime fields that DHCP typically communicates are of different
length than the lifetime field used by ND about default router (32bit vs
16bit if I am not mistaken).

If that implies a major rehaul to DHCP implementation of timing in
general then I would oppose suggesting such a change.

If that implies that DHCP implementation does not change its way of
managing its 32bit timing for usual DHCP matters, but just stores 16bit
Default Route lifetime values in a conf file, and communicates these
fields to Client in a DHCP Message, then I would agree with it.

If that implies that ND should be modified such at the expiration of the
Default Router lifetime it fires a RS _and_ (optionally) a DHCP Request
ORO 64 asking anew the Default Router, then I would not oppose it either.

Does this explanation add to clarity of my initially short phrase?

Alex

---

From: maximilien mouton <[email-masked]>
Date: Tue, 13 Sep 2011 19:48:18 +0200

Hi Ted,

Le 13/09/2011 15:01, Ted Lemon a écrit :
> On Sep 13, 2011, at 12:40 AM, maximilien mouton wrote: In this case
> an Information-Request when client's lifetime expires (or is close
> to) is sufficient especially if lifetime's upper limit is higher.
>
>  DHCP protocol to propose that the client include that lifetime in
> its calculations for when to renew.

Even if I grant It would imply big changes in DHCP, I think it would be
interesting for DHCP to imitate ND dynamic behavior because in this
draft we are trying to challenge ND by allowing DHCP to provide an
entire IP/Internet configuration by its own.

Best regards,

Maximilien

> Adding an option is a minor extension.   I would oppose a major
> extension for this purpose; I don't know how the working group as a
> whole would feel about it, but I suspect there would be a great deal
> of skepticism.
>
> renewal timer, in the case of stateful.   So if you put a lifetime in
> a route option, I don't see what good it would do.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 17:55:39 +0000

On Sep 13, 2011, at 1:26 PM, Alexandru Petrescu wrote:
Does this explanation add to clarity of my initially short phrase?

I think so, yes.   I think it's fine to have an option in the config file that specifies a default route, or routes in general.   Putting a lifetime on that, I think, is impractical.   If the administrator wants a short lifetime on these routes, they should be setting a short lifetime on the addresses offered by the DHCP server, so that renewals come often enough to meet this need.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 17:56:30 +0000

On Sep 13, 2011, at 1:44 PM, Maximilien MOUTON wrote:

We never had a TTL on the route offered in DHCPv4.   Why is DHCPv6 different?

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 20:06:09 +0200

Le 13/09/2011 19:55, Ted Lemon a écrit :
> I think so, yes. I think it's fine to have an option in the config
> file that specifies a default route, or routes in general. Putting a
>  lifetime on that, I think, is impractical.

I can see the impracticality aspect reflected in the difference
16bit-vs-32bit ND-DHCP.

But when a Client receives a DHCP Advertise with fields about a default
router then it should copy these fields into local existing data
structures.  These data structures about the default route are what ND
maintains, and that includes a lifetime field.

A Client could ignore that lifetime field of the ND data structure, and
consider that entry permanent forever.

Or it could try to manage the time of life of that default router entry
in a coherent manner DHCP+ND, which implies deciding, among other
things, what to do when lifetime expires.

If the expiration of the DHCP lifetime implies triggering _only_ DHCP
messaging that would be less advantageous.

> If the administrator wants a short lifetime on these routes, they
> should be setting a short lifetime on the addresses offered by the
> DHCP server, so that renewals come often enough to meet this need.

I find it to be a stretch to link the lifetime of addresses to lifetime
of routes in the routing table.

It is possible that a Client does not have any address assigned by DHCP,
but needs a default router assigned by DHCP.  E.g. when using link-local
addresses (self formed) and be part of some global multicast group.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 18:22:41 +0000

On Sep 13, 2011, at 2:06 PM, Alexandru Petrescu wrote:
I find it to be a stretch to link the lifetime of addresses to lifetime
of routes in the routing table.

Could you please clearly articulate a use case where this option is necessary, and the existing proposed option is not adequate?   Please do not mention operating system data structures.   Please do not say "I find it to be the case that.."   Without a use case, I just don't see the point in discussing this further.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 13 Sep 2011 14:26:17 -0400

Ted Lemon wrote, on 09/13/2011 02:22 PM:
> Could you please clearly articulate a use case where this option is necessary,
> and the existing proposed option is not adequate?   Please do not mention
> operating system data structures.   Please do not say "I find it to be the case
> that.."   Without a use case, I just don't see the point in discussing this further.

+1

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 20:30:41 +0200

Le 13/09/2011 19:56, Ted Lemon a écrit :
>> Even if I grant It would imply big changes in DHCP, I think it
>> would be interesting for DHCP to imitate ND dynamic behavior
>> because in this draft we are trying to challenge ND by allowing
>> DHCP to provide an entire IP/Internet configuration by its own.
>

Did DHCPv4 already offer routes?  Is there a document thanks?

This is quite an interesting question, and at first it may confuse.

I suppose you mean "Time To Live", as it could be the lifetime of a
route (and not as the TTL field of IPv4 datagrams which is an integer of
hops, as hopcount, despite its "Time" in "TTL").

In this sense, indeed, the question can be raised why a route
communicated with DHCP should have a lifetime associated with it.  And
answers exist.

In another sense, in IPv6 the TTL of IP datagrams (the hopcount, not the
time value) is "Hop Limit".  ND's RA does communicate a suggested Hop
Limit value for end hosts to configure on their local data structures.
E.g. RFC4861 uses a "Cur Hop Limit" value in an RA.

We have debated locally about proposing that "Cur Hop Limit" in DHCP as
well, alternatively to it being communicated by DHCP.

(sorry for dissecting the TTL question).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 20:51:58 +0200

Le 13/09/2011 20:22, Ted Lemon a écrit :
>> I find it to be a stretch to link the lifetime of addresses to
>> lifetime of routes in the routing table.
>
> Could you please clearly articulate a use case where this option is
> necessary, and the existing proposed option is not adequate? Please
> do not mention operating system data structures. Please do not say
> "I find it to be the case that.." Without a use case, I just don't
> see the point in discussing this further.

What do you mean by "use case" so I can better detail how this default 
route option is necessary, thanks.

The existing proposed option does not accommodate several use-cases.

One particular case is a 3G+ operator using terminals whose default
routes are under the form "0.0.0.0 0.0.0.0 hso0" remark no address for
next hop, but an interface name (existing option does not communicate
interface names).  3G is mentioned as a use case in
draft-ietf-mif-dhcpv6-route-option-03 yet I believe 3G+ is not covered.
  Can I thus suggest that existing option is not adequate?

With respect to lifetimes: if you do not agree discussing lifetimes now
then you may agree discussing lifetimes when implementation feedback of
existing option is out.  I suppose there is currently no implementation
of the existing option, whereas implementation of
draft-mouton-mif-dhcpv6-drlo-00 does exist, as reflected in
http://www.ietf.org/mail-archive/web/mif/current/msg01166.html

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 19:15:56 +0000

On Sep 13, 2011, at 2:51 PM, Alexandru Petrescu wrote:

How does the existing implementation handle renewal?

What do you mean by "use case" so I can better detail how this default route option is necessary, thanks.

The 3G+ scenario is the first use case you've presented, so thanks for that.

If interface names are in fact required, that's interesting.   I really don't understand how that could work, though, since the DHCP server has no way to know what the client operating system is calling the interface.

Also, I'm a bit confused by the idea of an interface route with no router address in IPv6.   I will admit to being something of a tyro when it comes to these things, but I don't understand how that would work.   Does the client simply multicast every packet?   Is there an RFC or draft that documents how this works?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 13 Sep 2011 15:20:22 -0400

Ted Lemon wrote, on 09/13/2011 03:15 PM:
> Also, I'm a bit confused by the idea of an interface route with no router
> address in IPv6.   I will admit to being something of a tyro when it comes to
> these things, but I don't understand how that would work.   Does the client
> simply multicast every packet?   Is there an RFC or draft that documents how
> this works?

I'm guessing that's a point-to-point interface. So you don't need the next hop's
L2 address. You just send it down the tube and it gets at the other end. The
classic example is PPP.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 19:41:03 +0000

On Sep 13, 2011, at 3:20 PM, Simon Perreault wrote:
I'm guessing that's a point-to-point interface. So you don't need the next hop's
L2 address. You just send it down the tube and it gets at the other end. The
classic example is PPP.

Okay, that sort of makes sense, but it seems like it's impossible for the DHCP server to know what that interface is called, and easy to just have the client set up the routing since it knows what it's doing.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 13 Sep 2011 15:46:12 -0400

Ted Lemon wrote, on 09/13/2011 03:41 PM:
> Okay, that sort of makes sense, but it seems like it's impossible for the DHCP
> server to know what that interface is called, and easy to just have the client
> set up the routing since it knows what it's doing.

Agreed.

In any case it's still possible to describe a P-t-P route using the remote
endpoint's IP address instead of the interface name or index. So IMHO the 3G use
case is supported by the current draft.

Simon

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 22:39:05 +0200

Le 13/09/2011 21:46, Simon Perreault a écrit :
>>> I'm guessing that's a point-to-point interface. So you don't need
>>> the next hop's L2 address. You just send it down the tube and it
>>> gets at the other end. The classic example is PPP.
>>
>> Okay, that sort of makes sense, but it seems like it's impossible
>> for the DHCP server to know what that interface is called, and easy
>> to just have the client set up the routing since it knows what it's
>> doing.
>
> Agreed.
>
> In any case it's still possible to describe a P-t-P route using the
> remote endpoint's IP address instead of the interface name or index.

Except that when that default route is given by the DHCP Server this
latter may not know the remote endpoint's IP address.  It may be for
this reason why currently is a "0.0.0.0"; and also because it changes
with every new attachement which does not involve a new DHCP exchange.

One alternative could be to specify that the Client adds that default
route on the interface on which it received the Advertise.  Without this
clarification the Client does not know what to do with a "0.0.0.0
0.0.0.0" default route received in a DHCP message.

There may exist other alternatives.

But spec should say what the Client should do about a "0.0.0.0 0.0.0.0"
default route otherwise it can't insert it in its forwarding information
base.

Alex

  So IMHO the 3G use

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 22:41:20 +0200

> to just have the client set up the routing since it knows what it's

A Client with multiple interfaces has difficulty to set up its default
route properly when all the DHCP Server tells it is  a "0.0.0.0 0.0.0.0".

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 22:44:30 +0200

Le 13/09/2011 21:20, Simon Perreault a écrit :
>> Also, I'm a bit confused by the idea of an interface route with no
>> router address in IPv6.   I will admit to being something of a tyro
>> when it comes to these things, but I don't understand how that
>> would work.   Does the client simply multicast every packet?   Is
>> there an RFC or draft that documents how this works?
>
> I'm guessing that's a point-to-point interface. So you don't need the
> next hop's L2 address. You just send it down the tube and it gets at
> the other end. The classic example is PPP.

YEs, it is a "no ARP" interface, but in some 3G+ it is not PPP.

Yes, the client just sends it down the tube.

But no, the Client can't set up that default route when all is being
given is "0.0.0.0".  It must tell the interface name.  The Client by
itself is not capable to decide how to insert that default router entry
in its routing table, it just can't solve "0.0.0.0" on some interface
name so it must be told the interface name by some spec or mechanism.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 22:51:56 +0200

Le 13/09/2011 21:15, Ted Lemon a écrit :
>> With respect to lifetimes: if you do not agree discussing lifetimes
>> now then you may agree discussing lifetimes when implementation
>> feedback of existing option is out. I suppose there is currently no
>> implementation of the existing option, whereas implementation of

The existing implementation of draft-mouton-mif-dhcpv6-drlo-00 does not
handle renewal.  We're facing too many options about it: should it
RENEW?  Should it send an RS as well?  This is up to debate.  But it is
related only to the default route, not the other routes.

Remark the debate comes from the lifetime of ND as well.

>> What do you mean by "use case" so I can better detail how this
>> default route option is necessary, thanks.
>
> If interface names are in fact required, that's interesting. I really
>  don't understand how that could work, though, since the DHCP server
> has no way to know what the client operating system is calling the
> interface.
>
> when it comes to these things, but I don't understand how that would
> work. Does the client simply multicast every packet? Is there an RFC
> or draft that documents how this works?

Just puts it on the pipe, but needs to know on which pipe when several
interfaces are available.

I would like to add further:
- we do not try to suggest problems for others to solve, but would like
   to participate in the solution space.
- in the use case of use Mobile IP, the default route on a 3G+ terminal
   points actually to a virtual interface tunnel name, and not to a real
   interface.  (the real interface is used as target of a host-specific
   route towards the Mobile IP home agent.)
- in the case of using a v6-v4 transition method, the default IPv6
   route points to a virtual interface as well, and not to a real
   interface.  In this case as well, the default route communicated by
   DHCPv6 to a multiply-interfaced Client needs potentially much more
   than simply dst address of the default router.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Sep 2011 22:59:10 +0200

Le 13/09/2011 20:26, Simon Perreault a écrit :
>> necessary, and the existing proposed option is not adequate?
>> Please do not mention operating system data structures.   Please do
>> not say "I find it to be the case that.."   Without a use case, I
>> just don't see the point in discussing this further.
>
> +1

-1

One particular use case is:

DHCP communicates a default route without lifetime to Client.

Client inserts the default route without lifetime.

Some implementations may set that mandatory ND local field to arbitrary
values- some will expire it some won't.

Some Clients will run RS after that time others won't.

One other case is the following, for WiFi hotspot:

DHCP communicates the default route wihtout MAC address

Client will receive the defualt route and install it.

When it first uses it it will necessarily generate an NS-NA in order to
solve the default router's address into the MAC address.  This
additional NS-NA is noise on wire, compared to if the MAC address were
communicated in the first place.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 21:27:15 +0000

On Sep 13, 2011, at 4:51 PM, Alexandru Petrescu wrote:

That doesn't even make sense.   Why does a default route need a lifetime, but the other routes don't?   Why do we need a default route option at all?   It doesn't look like the use case you've proposed justifies this option.

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 21:31:03 +0000

Could you please be more specific what is this 3G+? I mean use of DHCPv4 for address config is extremely rare on real 3GPP accesses and stateful DHCPv6 for address config is not on any 3GPP spec version (save PD) at least..

Sent from my Windows Phone
________________________________
From: ext Alexandru Petrescu
Sent: 13.9.2011 23:44
To: [email-masked]
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2011 21:31:20 +0000

On Sep 13, 2011, at 4:59 PM, Alexandru Petrescu wrote:
One particular use case is:

Sorry, to be clear, a use case is an example of usage that requires new protocol action, because existing functionality cannot address the use case.   Use cases have to be real, concrete things, not hypotheticals.   I can always make up a hypothetical example to justify any sort of protocol extension, but if there is no real-world use case that requires it, all the work of doing that protocol extension is wasted.

What you've given in this particular message are a couple of examples of how the option could be used.   These are not relevant use cases, because they could also be addressed with the existing proposed option.   That is, they do not motivate additional work.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Sep 2011 00:20:16 +0200

Le 13/09/2011 23:27, Ted Lemon a écrit :
>> The existing implementation of draft-mouton-mif-dhcpv6-drlo-00 does
>> not handle renewal. We're facing too many options about it: should
>> it RENEW? Should it send an RS as well? This is up to debate. But
>> it is related only to the default route, not the other routes.
>
> That doesn't even make sense. Why does a default route need a
> lifetime, but the other routes don't?

Because, most if not all IPv6 implementations come with a mandatory ND
implementation.  That has the notion of "default router".  That default
router has a mandatory lifetime field.  There can be several routers on
a link acting as a "default router" and their lifetime.

RFC4861 syas "The Router Lifetime applies only to the router's
usefulness as a default router; it does not apply to information
contained in other message fields or options.  Options that need [...]"
  in sync with lifetimes communicated by ospf.

> Why do we need a default route option at all?

Because it is more important than the specific routes.  It must work
when everything else fails.

Must be distinguishable when several present; must be reliably renewed
even though no global address assigned with DHCP; must be in sync
with what RA does. Must tell the number of hops between Client the gw
address.  Etc.

If some of these aspects fail the Client without a default route may be
unreachable by arbitrary nodes trying to ICMP diagnose it.

On another hand, a specific route incompletely specified may not do that
much harm to Client.

> It doesn't look like the use case you've proposed justifies this
> option.

Hmmm...

I am not sure whether you're saying that these aspects (interface name
resolution, number of hops, sync with ND/rt protocols) are necessary for
all other specific routes as well.  Or you're saying simply that the
currrrent draft-mif is ok as it is with its way of being extended.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Sep 2011 00:29:04 +0200

Le 13/09/2011 23:31, [email-masked] a écrit :
> Could you please be more specific what is this 3G+?

3G+ just as 3G is a market to end user label means of advertising more
speed.  Similar to what WiFi is to 802.11.

> I mean use of DHCPv4 for address config is extremely rare on real
> 3GPP accesses

Yes, DHCP rare on 3GPP access, and IPv6 rare as well, let alone DHCPv6.

In some situations I experienced DHCPv6 may provide routing
configuration via WiFi to a Windows Phone also connected on 3G+.  That
routing configuration would need to tell the Windows Phone its IPv6
default route via the 3G+ access.

> and stateful DHCPv6 for address config is not on any 3GPP spec
> version (save PD) at least..

Not sure about it.  I agree that PD may be in the 3GPP spec, but I am
almost sure DHCPv6 is also specified by 3GPP as an alternative means to
configure a Client, alternate to IPv6 stateless autoconfig.

If 3GPP uses DHCPv6 to configure addresses to Clients then it may be
used to configure the default route as well, for more efficiency.

Alex

> ------------------------------------------------------------------------
>
>
>
>
> Sent: 13.9.2011 23:44 To: [email-masked] Subject: Re: [mif] Comments on
> draft-mouton-mif-dhcpv6-drlo-00
>
>>> Also, I'm a bit confused by the idea of an interface route with
>>> no router address in IPv6. I will admit to being something of a
>>> tyro when it comes to these things, but I don't understand how
>>> that would work. Does the client simply multicast every packet?
>>> Is there an RFC or draft that documents how this works?
>>
> itself is not capable to decide how to insert that default router
> entry in its routing table, it just can't solve "0.0.0.0" on some
> interface name so it must be told the interface name by some spec or
>  mechanism.
>
> Alex
>
>>
>> Simon
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Sep 2011 00:45:58 +0200

Le 13/09/2011 23:31, Ted Lemon a écrit :
> Sorry, to be clear, a use case is an example of usage that requires
> new protocol action, because existing functionality cannot address
> the use case.

The use case is a wifi-3G phone whose default route is provided by DHCP
on WiFi and must point to a virtual interface - current spec does not
allow for it.

Must also be expirable at the same time as ND - current spec does not
allow for it.

> Use cases have to be real, concrete things, not hypotheticals.

Protocol specs must be coherent in text and not hypotheticals either.
Or, current spec says "Each IPv6 route consists of an IPv6 next hop
address, an IPv6 destination prefix (a.k.a. the destination subnet), and
a host preference value for the route."

There is no preference in the draft.  And, non-hypothetical IPv6 routes
consist in more than nexthop, dstprefix, preference.  Examples are:
number of hops to reach that nexthop, interface name and lifetimes.

Protocol specs should be implementable.  Ideally, one would take the
implementation and write the draft literally after it; and less ideally
the other way around.

> I can always make up a hypothetical example to justify any sort of
> protocol extension, but if there is no real-world use case that
> requires it, all the work of doing that protocol extension is
> wasted.

The use cases I have described are all hands-on that I have
experimented several times.  They are not hypotheticals.

> What you've given in this particular message are a couple of
> examples of how the option could be used. These are not relevant use
> cases, because they could also be addressed with the existing
> proposed option. That is, they do not motivate additional work.

The proposed option is incomplete, not implemented, and missing some
reference to existing base.

It is difficult to suggest improvements to it because it takes a wrong
direction.  We have made some suggestions, and we did discuss f2f a few
times, and we are thankful for having taken some of our comments; but
not all messages get through.  This is one reason we suggest a different
option for default route.

Alex

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 06:08:11 +0000

> speed.  Similar to what WiFi is to 802.11.

Ok, so referring to 3GPP technologies I assume (not WiMAX for example).

> In some situations I experienced DHCPv6 may provide routing configuration
> via WiFi to a Windows Phone also connected on 3G+.  That routing
> configuration would need to tell the Windows Phone its IPv6 default route
> via the 3G+ access.

Do you mean the WiFi access would explicitly spell out 3G as the default
route for a node, or indirectly by the WiFi access telling it is low
priority default route (ref RFC4191) - and hence suggesting using some other
interfaces by default instead?

> Not sure about it.  I agree that PD may be in the 3GPP spec, but I am
almost
> sure DHCPv6 is also specified by 3GPP as an alternative means to configure
a
> Client, alternate to IPv6 stateless autoconfig.

I am absolutely sure 3GPP as of today does not specify Stateful DHCPv6 as an
option to configure client's WAN interface addresses on cellular interface.
There is only Prefix Delegation in Release-10, but even in Rel-10 case
client's WAN interface address is always configured with SLAAC. (Ref 3GPP
23.060 and 23.401 for more details). I have to say I don't recall
immediately what 3GPP specs says about client configuration on trusted WLANs
(but I would except also only SLAAC there as well, otherwise things like
netext's logical interface might be even bigger challenges to get working).

> If 3GPP uses DHCPv6 to configure addresses to Clients then it may be used
to
> configure the default route as well, for more efficiency.

It is true that DHCPv6 can be used to configure additional information
(stateless DHCPv6). Hence yes, specific routes and even maybe default route
could be configured via DHCPv6... but I don't see why default route would
be, as the Router Advertisements used by SLAAC already provide default route
information.

Best regards,

	Teemu

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Sep 2011 11:15:33 +0200

Le 14/09/2011 08:08, [email-masked] a écrit :
>> 3G+ just as 3G is a market to end user label means of advertising
>> more speed.  Similar to what WiFi is to 802.11.
>
>> configuration via WiFi to a Windows Phone also connected on 3G+.
>> That routing configuration would need to tell the Windows Phone its
>> IPv6 default route via the 3G+ access.
>
> Do you mean the WiFi access would explicitly spell out 3G as the
> default route for a node, or indirectly by the WiFi access telling it
> is low priority default route (ref RFC4191) - and hence suggesting
> using some other interfaces by default instead?

YEs, in this way.

>> Not sure about it.  I agree that PD may be in the 3GPP spec, but I
>>  am almost sure DHCPv6 is also specified by 3GPP as an alternative
>>  means to configure a Client, alternate to IPv6 stateless
>> autoconfig.
>
> I am absolutely sure 3GPP as of today does not specify Stateful
> DHCPv6 as an option to configure client's WAN interface addresses on
>  cellular interface.

Hmm... in a sense I agree with you - currently in 3GPP specs 23401-a40
and 24301-a30 there is DHCPv6 only as PD and as Stateless DHCPv6, not as
stateful DHCPv6.  I have limited knowledge of these documents.

However, I have remarks.

In many places the term "default prefix" is used.  For example like this:
> IPv6 Prefix Delegation via DHCPv6 Optionally a single network prefix
> shorter than the default /64 prefix may be assigned to a PDN
> connection. In this case, the /64 default prefix used for IPv6
> stateless autoconfiguration will be allocated from this network
> prefix

This is difficult to understand because SLAAC has no "default prefix"
(grep rfc4862).

24.301-a30 says often GW allocates via RA like this:
> The PDN GW allocates a globally unique /64 IPv6 prefix via Router
> Advertisement to a given UE.

But this is so difficult for me to understand because RA RFC text never
says an RA "allocates" some prefix.  This allocation action is typically
a DHCP action, not RA.  The RA simply advertises an allocation already
done by DHCP or administrator or ospf.

In a number of other places the 3GPP spec is incoherent with respect to
who is the "Requesting Router" - the UE or the PDN GW (at a moment the
GW is a DHCP client requesting a prefix, at another moment it is the UE
being a requesting router).  For me it is not clear how a Requesting
Router below another Requesting Router can work.

Another remark is that Stateless DHCP _could_ be used to communicate
default routes to Clients because the data about default route is not
state which should be maintained at server.  It is possible for a 3G
client to simply receive a DHCP Advertise which may be empty and still
set a correct default route.

> There is only Prefix Delegation in Release-10, but even in Rel-10
> case client's WAN interface address is always configured with SLAAC.

Hmmm... I would not rely on 3GPP specs to make a terminal run ok on
WiFi.  I would guess a 3GPP spec about WiFi is just FYI(?) no offense.

------------

May I try to interpret further the DHCP text in 3GPP specs, IMHO.

It is unclear to me why the 23401 3GPP spec says that "The UE acts as a
"Requesting Router"" requesting a Prefix.  An entire Prefix (in addition
to the onlink prefixes) is useful only if that UE is a Mobile Router,
giving addresses further to some LFNs.  Otherwise it is not clear why do
Prefix Delegation to a UE Requesting Router.  Yet the spec never says
"Mobile Router".

If it makes sense for this UE to actually be a MR, and to run DHCPv6-PD
then it could make sense to use DHCPv6 for address and default route
configuration as well, instead of DHCPv6+SLAAC - simply the number of
messages is reduced, and configuration of addresses/routes/prefixes is
centralizely managed.

But this is just personal opinion, motivating the use of DHCPv6 for
default route in 3GPP.

> (Ref 3GPP 23.060 and 23.401 for more details).

Thanks for ref 23.060.

> I have to say I don't recall immediately what 3GPP specs says about
> client configuration on trusted WLANs (but I would except also only
> SLAAC there as well, otherwise things like netext's logical interface
> might be even bigger challenges to get working).

Hmmm... in a sense the netext logical interface is to me still unclear.

>> If 3GPP uses DHCPv6 to configure addresses to Clients then it may
>> be used to configure the default route as well, for more
>> efficiency.
>
> It is true that DHCPv6 can be used to configure additional
> information (stateless DHCPv6). Hence yes, specific routes and even
> maybe default route could be configured via DHCPv6... but I don't see
> why default route would be, as the Router Advertisements used by
> SLAAC already provide default route information.

_If_ the UE is a Mobile Router and uses DHCPv6-PD to request its prefix
(DHCPv6-PD is the only way it can get a prefix for its LFNs) then it may
make sense to use same DHCP software to request routes and addresses.

What do you think?

Alex

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 10:26:11 +0000

> > stateless autoconfiguration will be allocated from this network prefix
> 

It refers to unique /64 prefix allocated for a PDN connection.

> But this is so difficult for me to understand because RA RFC text never
says
> an RA "allocates" some prefix.  This allocation action is typically a DHCP
> action, not RA.  The RA simply advertises an allocation already done by
DHCP
> or administrator or ospf.

Maybe the terminology is not clearest, but it means /64 prefix is advertised
to the PDN connection. It is different topic then where the PDN GW got the
addresses (statically allocated pool or by DHCPv6 or whatever means).

The "allocate" text probably comes from the view that it is P-t-P connection
between UE and PDN GW and hence there is just single UE that "gets" the
whole /64 "allocated" for its use.

> In a number of other places the 3GPP spec is incoherent with respect to
who
> is the "Requesting Router" - the UE or the PDN GW (at a moment the GW is a
> DHCP client requesting a prefix, at another moment it is the UE being a
> requesting router).  For me it is not clear how a Requesting Router below
> another Requesting Router can work.

In my understanding the PDN GW can use DHCPv6 Prefix Delegation to get an
address pool from where to "advertise" /64s for different UEs PDN
connections. 

Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6 Prefix
Delegation to get prefixes for advertisement on local area networks (such as
"MiFi hotspot").

> "Requesting Router"" requesting a Prefix.  An entire Prefix (in addition
to the
> onlink prefixes) is useful only if that UE is a Mobile Router, giving
addresses
> further to some LFNs.  Otherwise it is not clear why do Prefix Delegation
to a
> UE Requesting Router.  Yet the spec never says "Mobile Router".

UE acts as requesting router in order to behave as a router. I understand
not using term Mobile Router there, as the UE does not necessarily implement
any "IP Mobility" solutions (e.g. DSMIP6). UE just acts as a router.

> If it makes sense for this UE to actually be a MR, and to run DHCPv6-PD
then
> it could make sense to use DHCPv6 for address and default route

It could, but as of now it is not specified to be possible. 3GPP UE always
uses SLAAC to number its cellular WAN interface (unnumbered model is not
supported), including getting default route pointing to cellular interface.
After SLAAC, UE acting as router MAY use DHCPv6 PD to get prefixes for
advertisement in "southbound" local area networks.

Because SLAAC is always used and UE gets its IPv6 default route that way,
there is currently no need to use DHCPv6 to specify default routes.

As always, things may change in the future and that's one reason why I'm ok
for defining default route option for DHCPv6.

Best regards,

	Teemu

---

From: Hui Deng <[email-masked]>
Date: Fri, 16 Sep 2011 13:42:27 +0800

Hello all

Observations from the mailing list discussion about this draft is:
the Scenario author proposed related to 3GPP is not valid based on current
specification.
Because SLAAC is always used and UE gets its IPv6 default route that way,
there is currently no need to use DHCPv6 to specify default routes.
So whether we would like to have different option for default route option
have to wait for future evolution opportunity.

could I summarize the discussion like
Whether we need to specify future purpose option at this moment?

Thanks for this detail discussion

-Hui

2011/9/14 <[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Sep 2011 16:37:08 +0200

Hello Hui,

Thank you for summarising the discussion.  Allow me to comment.

Le 16/09/2011 07:42, Hui Deng a écrit :
> Hello all Observations from the mailing list discussion about this
> draft is: the Scenario author proposed related to 3GPP is not valid
> based on current specification. Because SLAAC is always used and UE
> gets its IPv6 default route that way, there is currently no need to
> use DHCPv6 to specify default routes.

Indeed currently 3GPP specs imply that SLAAC is used for default route
(and not DHCP, although DHCP is used for other aspects such as Prefix
Delegation and stateless parameters).

> So whether we would like to have different option for default route
> option have to wait for future evolution opportunity.

For 3GPP yes, maybe future evolution will involve default route with
DHCP, or maybe not.

> could I summarize the discussion like Whether we need to specify
> future purpose option at this moment?

If we take only current 3GPP, and only 3GPP overall, into account then
no, there is seemingly no need to specify a specific option for default
route.

On another hand.  A unique DHCP default route option that could apply to
non-3GPP, and maybe to future 3GPP, would be useful, considering that IP
runs over non-3GPP and over 3GPP in same manner.

Additionally, consider that the current MIP draft-ietf route option does
specify a means to offer default route as a particular case of normal
route.

Do you think it is possible to specify default route in draft-ietf-
route option (as currently it does) and still specify it in another way
in a future document?

(a default route is more special than a typical route.  It has a
number of other parameters that need to be present differently.  For
example: (1) the associated lifetime must be present in the ND default
router list (whereas the other routes don't), (2) MAC address is useful
(whereas for the other routes maybe the next hop may not be on the same
link).  Not to mention that a failing default route disconnects the Host
from a potentially large part of the Internet.)

Alex

> Thanks for this detail discussion -Hui
>
> 2011/9/14 <[email-masked]
> <mailto:[email-masked]>>
>
>> This is difficult to understand because SLAAC has no "default
>> prefix" (grep rfc4862).
>
>>> The PDN GW allocates a globally unique /64 IPv6 prefix via
>>> Router Advertisement to a given UE.
>>
>> But this is so difficult for me to understand because RA RFC text
> never says
>> action, not RA.  The RA simply advertises an allocation already
> done by DHCP
> Maybe the terminology is not clearest, but it means /64 prefix is
> advertised to the PDN connection. It is different topic then where
> the PDN GW got the addresses (statically allocated pool or by DHCPv6
>  or whatever means).
>
> The "allocate" text probably comes from the view that it is P-t-P
> connection between UE and PDN GW and hence there is just single UE
> that "gets" the whole /64 "allocated" for its use.
>
>> In a number of other places the 3GPP spec is incoherent with
> respect to who
> In my understanding the PDN GW can use DHCPv6 Prefix Delegation to
> get an address pool from where to "advertise" /64s for different UEs
>  PDN connections.
>
> Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6
> Prefix Delegation to get prefixes for advertisement on local area
> networks (such as "MiFi hotspot").
>
>> "Requesting Router"" requesting a Prefix.  An entire Prefix (in
> addition to the
>> further to some LFNs.  Otherwise it is not clear why do Prefix
> Delegation to a
> UE acts as requesting router in order to behave as a router. I
> understand not using term Mobile Router there, as the UE does not
> necessarily implement any "IP Mobility" solutions (e.g. DSMIP6). UE
> just acts as a router.
>
>> If it makes sense for this UE to actually be a MR, and to run
> DHCPv6-PD then
>> configuration as well, instead of DHCPv6+SLAAC - simply the number
>>  of messages is reduced, and configuration of
> addresses/routes/prefixes is
>> centralizely managed.
>
> It could, but as of now it is not specified to be possible. 3GPP UE
> always uses SLAAC to number its cellular WAN interface (unnumbered
> model is not supported), including getting default route pointing to
>  cellular interface. After SLAAC, UE acting as router MAY use DHCPv6
>  PD to get prefixes for advertisement in "southbound" local area
> networks.
>
> Because SLAAC is always used and UE gets its IPv6 default route that
> way, there is currently no need to use DHCPv6 to specify default
> routes.
>
> As always, things may change in the future and that's one reason why
> I'm ok for defining default route option for DHCPv6.
>
> Best regards,
>
> Teemu
>
> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Sep 2011 16:49:07 +0200

Le 14/09/2011 12:26, [email-masked] a écrit :
>>> IPv6 Prefix Delegation via DHCPv6 Optionally a single network
>>> prefix shorter than the default /64 prefix may be assigned to a
>>> PDN connection. In this case, the /64 default prefix used for
>>> IPv6 stateless autoconfiguration will be allocated from this
>>> network prefix
>>

Hm.. I agree, it may be only me who confuses 3GPP "default prefix" with
"IP default route".

>> never says an RA "allocates" some prefix.  This allocation action
>> is typically a DHCP action, not RA.  The RA simply advertises an
>> allocation already done by DHCP or administrator or ospf.
>

If it is "allocated" for PtP connection for like-PPP then yes (although
I am not sure what the PPPv6 spec uses "allocate"), but that should be
"advertised" when used with RA.

Allocation of a prefix may happen in a number of ways like DHCP, manual,
router renumbering, but never RA.

>> respect to who is the "Requesting Router" - the UE or the PDN GW
>> (at a moment the GW is a DHCP client requesting a prefix, at
>> another moment it is the UE being a requesting router).  For me it
>> is not clear how a Requesting Router below another Requesting
>> Router can work.
>

Hmmm... but I don't understand how a UE can be a Requesting Router at
the same time as the PDN-GW being a RR.

If the MiFi hotspot router requests a /64 prefix from a PDN-GW which has
only /64 prefixes then the number of routing entries in the PDN-GW may
double.

Second, if the MiFi hotspot router is a RR then I suppose the PDN-GW
must be a delegating router for it (DR); the spec doesn't say, it says
just it's a RR. (if I read correctly).

>> It is unclear to me why the 23401 3GPP spec says that "The UE acts
>> as a "Requesting Router"" requesting a Prefix.  An entire Prefix
>> (in addition
> to the
>> Delegation
>> DHCPv6-PD
>> addresses/routes/prefixes is centralizely managed.
>

Yes, me too,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Sep 2011 16:51:18 +0200

(small typo below "MIF" instead of "MIP")

Alex

Le 17/09/2011 16:37, Alexandru Petrescu a écrit :
>> draft is: the Scenario author proposed related to 3GPP is not
>> valid based on current specification. Because SLAAC is always used
>> and UE gets its IPv6 default route that way, there is currently no
>> need to use DHCPv6 to specify default routes.
>
> Indeed currently 3GPP specs imply that SLAAC is used for default
> route (and not DHCP, although DHCP is used for other aspects such as
> Prefix Delegation and stateless parameters).
>
>> So whether we would like to have different option for default
>> route option have to wait for future evolution opportunity.
>
> If we take only current 3GPP, and only 3GPP overall, into account
> then no, there is seemingly no need to specify a specific option for
> default route.
>
> On another hand. A unique DHCP default route option that could apply
> to non-3GPP, and maybe to future 3GPP, would be useful, considering
> that IP runs over non-3GPP and over 3GPP in same manner.
>
                             sorry I meant MIF

Alex

> specify a means to offer default route as a particular case of
> normal route.
>
> route option (as currently it does) and still specify it in another
> way in a future document?
>
> example: (1) the associated lifetime must be present in the ND
> default router list (whereas the other routes don't), (2) MAC address
> is useful (whereas for the other routes maybe the next hop may not be
> on the same link). Not to mention that a failing default route
> disconnects the Host from a potentially large part of the Internet.)
>
> Alex
>
>
>> the PDN GW got the addresses (statically allocated pool or by
>> DHCPv6 or whatever means).
>>
>> get an address pool from where to "advertise" /64s for different
>> UEs PDN connections.
>>
>> Additionally, in rel-10, also UE connected to PDN GW can use
>> DHCPv6 Prefix Delegation to get prefixes for advertisement on local
>> area networks (such as "MiFi hotspot").
>>
>> necessarily implement any "IP Mobility" solutions (e.g. DSMIP6).
>> UE just acts as a router.
>>
>>> configuration as well, instead of DHCPv6+SLAAC - simply the
>>> number of messages is reduced, and configuration of
>> It could, but as of now it is not specified to be possible. 3GPP
>> UE always uses SLAAC to number its cellular WAN interface
>> (unnumbered model is not supported), including getting default
>> route pointing to cellular interface. After SLAAC, UE acting as
>> router MAY use DHCPv6 PD to get prefixes for advertisement in
>> "southbound" local area networks.
>>
>> Because SLAAC is always used and UE gets its IPv6 default route
>> that way, there is currently no need to use DHCPv6 to specify
>> default routes.
>>
>> As always, things may change in the future and that's one reason
>> why I'm ok for defining default route option for DHCPv6.
>>
>> Best regards,
>>
>> Teemu
>>

---

From: <[email-masked]>
Date: Mon, 19 Sep 2011 08:33:12 +0000

> Hmmm... but I don't understand how a UE can be a Requesting Router at the
> same time as the PDN-GW being a RR.

PDG-GW can use DHCPv6 PD to ask for a pool of addresses it uses for UEs (or
it may have a locally provisioned pool), and from where it can further
delegate prefixes downstream (in DR role) to those UEs that implement RR
function.

> only /64 prefixes then the number of routing entries in the PDN-GW may

Yes! That is one big reason for existence of draft-ietf-dhc-pd-exclude-03
that optimizes routing entries in these kinds of scenarios on 3GPP accesses,
but also elsewhere - there was interest from fixed side for this as well.
The exclude option optimizes routing entries on gateway but with a
deployment-scenario/network setup dependent possible tradeoff of increased
address space usage.

> Second, if the MiFi hotspot router is a RR then I suppose the PDN-GW must
> be a delegating router for it (DR); the spec doesn't say, it says just
it's a RR. (if
> I read correctly).

Did you look at the 23.401 V10.4.0 (the latest version) section 5.3.1.2.6
that says it clearly: "The PDN GW acts as the DHCP server and fulfils the
role of a "Delegating Router" according to RFC 3633".

Best regards,

	Teemu

---

From: maximilien mouton <[email-masked]>
Date: Mon, 26 Sep 2011 10:42:13 +0200

Hi Simon and Ted,

>> just don't see the point in discussing this further.

First, I think we can say that there is a consensus on the fact that
DHCP should have an option including default router.

Second, why a specific option for default route rather than specify it
in route option?

You can notice that router option and static route option (the stateful
one) are defined separately since rfc 2132 (DHCP Options).
Moreover, rfc 3442 (Route Option for DHCP version 4) has a similar point
of view than what we propose with DRLO.

But beside this history point here is a scenario explaining the need of
specific option for default route:
Imagine a realistic network in which in the same prefix is, a limited
resource device not able to carry more than a default route (see
previous discussion with Alex), a classic device like a laptop with one
interface and a MIF device which want to run route option.
A reasonable configuration is DRLO for 2 the two first type of device
and DRLO+route option for the third (less frequent case).

In the opposit specify specific routes without default route may be
useful for instance for security or accounting reasons.

Maximilien

---

From: maximilien mouton <[email-masked]>
Date: Mon, 26 Sep 2011 10:43:38 +0200

Hi Ted again,

> We never had a TTL on the route offered in DHCPv4. Why is DHCPv6

DHCPv6 could be different because of ND.
Why include a lifetime in default router list option(DRLO)?

ND has been chosen as the best way for default router configuration
because it provides a dynamic autoconfiguration.

But in some case RA is not set or not desirable. This is what describes
Ralph Droms in draft-droms-dhc-dhcpv6-default-router-00. This is why
DHCP should provide default router also.

Use cases for using default router lifetime are actually each cases in
which you can use ND for autoconf and either you can't or don't want to.
An example of scenario is given in the draft.

As we are here challenging ND as an autoconfiguration mechanism we
propose a solution which tries to imitate its dynamic behavior. This is
why we propose a lifetime.
Here's a concrete case to illustrate this:

A client has multiple default routers available. Usually if those
routers use RA if the selected default router fails, the connectivity of
the client is down while the lifetime of the router in its default
router list is not null. At this time another default router is selected.
But if a static configuration is used without lifetime, as far as I
know, the default router list is not updated and the client connectivity
is never recovered whereas it could be.
The default router lifetime could solve this problem by making the
failed router expire in the client's default router list and let another
one take its place.

We receive also questions about the interest of providing a link layer
address.
Why a link layer address field?

Because it avoids unnecessary NS/NA exchange which represents an economy
of network resources (very useful for some resource constraint networks)
and a gain of time because client don't need to wait for NA anymore.
This field is also useful if ND is nor present in the link between the
client and the router.

Maximilien

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Sep 2011 15:07:36 +0200

Maximilien,

With respect to one particular point you mention below:

Le 26/09/2011 10:42, maximilien mouton a écrit :
>>> Could you please clearly articulate a use case where this option
>>> is necessary, and the existing proposed option is not adequate?
[...]
> You can notice that router option and static route option (the
> stateful one) are defined separately since rfc 2132 (DHCP Options).
> Moreover, rfc 3442 (Route Option for DHCP version 4) has a similar
> point of view than what we propose with DRLO.

Looking through RFC2132 and RFC3442 I understand that DHCPv4 uses
distinct options for classful - and incidentally default - route (option
code 33), than for classless routes (121).  The reason for a new option
121 seems to have been the classlessness absence in classful routes at
thetime, and worse 33 option seems non-extensible.

Nonetheless, the IPv4 software ended up with distinct options: one for
default route and one for classless routes.  It would be little
straightforward to port that IPv4 software to IPv6 if this latter had
only one option for both route and default route.

Alex
[...]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Sep 2011 15:06:36 +0000

On Sep 26, 2011, at 9:07 AM, Alexandru Petrescu wrote:

I personally consider it an unfortunate artifact of the way the classless static routes option evolved that we weren't able to have it support all routes, including the default route.   It's always a bad idea to have two ways of specifying the same information—it creates a very clear potential for interoperability problems.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 26 Sep 2011 11:08:38 -0400

> I personally consider it an unfortunate artifact of the way the classless static routes option evolved that we weren't able to have it support all routes, including the default route.   It's always…

s/interoperability/interoperability and operational/

Marc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Sep 2011 15:14:10 +0000

On Sep 26, 2011, at 4:42 AM, maximilien mouton wrote:
Imagine a realistic network in which in the same prefix is, a limited
resource device not able to carry more than a default route (see
previous discussion with Alex),

We hear a lot about fictitious devices that have bizarre limitations like this.   The reason, for instance, that DHCP only allows 576 byte packets by default was a theory that there might be some device in the network that wouldn't have buffer space for a larger packet.

I've never actually seen such a device in the wild, and am skeptical that any such device is likely to exist in the future.   If it's got enough memory to run DHCP, it's got enough memory to extract the default route from an option carrying a selection of routes, and it almost certainly also has enough memory to keep a full routing table anyway.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Sep 2011 18:37:43 +0200

This is about text in document 23401-a50 V10.5.0 of 3GPP 2011-09,
section 5.3.1.2.6.

> It refers to unique /64 prefix allocated for a PDN connection.

Teemu, let me bring back this text again.

"unique" is not the same as "default".  Each one such word has a
specific meaning.  Each is implemented differently.

> that "gets" the whole /64 "allocated" for its use.

I can hear the similar use of 'allocate' in PtP ppp rfc.

But
The use of the word "allocate" in this doc is ambiguous.

There exist IETF docs SLAAC non-PPP methods which _do_ allocate
prefixes, this makes think an MTC-inclined reader to confuse even further.

The terminology in this spec should be clarified to say "advertized"
instead of "allocated".

The same with section's use of "assigned".

> get an address pool from where to "advertise" /64s for different UEs

An "address pool" (a set of distinct /128 addresses) is not the same as
a "prefix".  Prefix Delegation can not be used to obtain address pools,
but prefixes.

> networks (such as "MiFi hotspot").

How?

>> (in addition to the onlink prefixes) is useful only if that UE is
>> a Mobile Router, giving addresses further to some LFNs.  Otherwise
>> it is not clear why do Prefix Delegation
> to a

Ok that not implementing NEMO then not MR.

But an UE which is a Router (DHC Requesting Router, forwards between 3g
and wifi ifaces, etc.) should be called something more powerful than
just "User Equipment".  It's something that offers Internet access to
other User Equipments.

>> DHCPv6-PD then it could make sense to use DHCPv6 for address and
>> default route configuration as well, instead of DHCPv6+SLAAC -
>> simply the number of messages is reduced, and configuration of
> It could, but as of now it is not specified to be possible.

Maybe better could be done.  An implementer optimizing the amount of
complexity on terminal would use just DHCPv6 (if available) for
address/prefix/defaultroute, (not RA) - easier to administer in some cases.

> 3GPP UE always uses SLAAC to number its cellular WAN interface
> (unnumbered model is not supported), including getting default route
>  pointing to cellular interface.

Well, in IPv4 some 3G+ implementations, the driver setting up the
interface does not forcefully assign neither address nor default route
on that in interface - it just tells them so some other smart middleware
can.

Recent ISC DHCPv6 Client implementations do the same on Ethernet: they
don't forcefully assign addresses/prefixes/dr that are extracted from
the received DHCP messages... they just tell them so other smart
middleware can assign it.

In a MIF device one would't want the network to forcefully impose where
the default route should go.

> After SLAAC, UE acting as router MAY use DHCPv6 PD to get prefixes
> for advertisement in "southbound" local area networks.

SLAAC could be used _only_ to do some things which DHCP doesn't: MTU,
HopLimit, on-link or off/link prefix - that's about it.  No need to do
more than that when DHCP can (address, default route, prefix for further
advertisement, dns, more).

This makes it easier to control the assignment of prefixes and routes in
central DHCP conf files in the network.

>  way, there is currently no need to use DHCPv6 to specify default

It is doubtful in a MIF terminal to have the network impose the default
one way or another.  It is good to have as much alternatives as possible
for the default route: SLAAC, DHCP, more.

>  I'm ok for defining default route option for DHCPv6.

I agree with you.

Section 5.3.1.2.6 of 3GPP doc 23401-a50 text which bothers:
> Optionally a single network prefix shorter than the default /64
> prefix may be assigned to a PDN connection.

Ok, so a /56 is assigned to a PDN connection.

> In this case, the /64 default prefix used for IPv6 stateless
> autoconfiguration will be allocated from this network prefix;

Ok, so a /64 is extracted from that /56, and used by SLAAC, supposedly
advertised to the PDN connection.  But earlier, the _/56_ was 'assigned'
to that PDN connection.  Did the text really mean that the /56 was
'assigned' to a PDN connection?  Or was it just preventive setting aside
of a /56 for a PDN connection yet to materialize, in the same way as the
'provisioned' used later in the text?  Better just use one.

> the remaining address space from the network prefix can be delegated
> to the PDN connection using prefix delegation

Ok, it is about the remaining address space left after the /56 was
extracted a /64.   I believe that to be 254 other /64s or so.

Does it mean that the UE may do DHCP Prefix Delegation to request these
prefixes?  If yes, then UE will not use them on the PDN connection, but
on another connection (you name it 'southbound' elsewhere).

In this sense this remaining address space is _not_ delegated to the PDN
connection but to the UE to use on other connections.

> after the default bearer establishment

Again - what is 'default' in 'default bearer establishment' - is it
'default bearer' or 'default establishment'?  In both cases I see it has
no relationship with 'default router' nor 'default route'.

> and IPv6 prefix allocation via IPv6 stateless address
> autoconfiguration as defined in clause 5.3.1.2.2.

IPv6 stateless address autoconfiguration does not do IPv6 prefix
allocation.  This sentence is purely wrong and should be corrected.

> When PLMN based parameter configuration is used, the PDN GW provides
> the requested IPv6 prefix from a locally provisioned pool.

Is this 'provisioned' pool containing a set of prefixes or of addresses?

Is that 'provisioned' word the same as the initial 'assigned' /56 above
("Optionally a single network prefix shorter than the default /64 prefix
may be _assigned_ to a PDN connection").

> When external PDN based IPv6 prefix allocation is used, the PDN GW
> obtains the prefix from the external PDN. [*]

How does the PDN GW obtain the prefix from the external PDN?  Is it by
using DHCPv6 Prefix Delegation?  I am asking because there exist no
other way to automatically (no human intervention) request and obtain
prefixes.

I assume DHCPv6-PD is meant by the above.  IF so it should say so.

> Note: Allocation of IPv6 prefixes with flexible prefix length can
> leverage e.g. local configuration on the PDN GW or interaction with
> the AAA server.

I do not quite understand this.

In general, I agree a network should offer a router more than just a
/64, in particular if that router had Ethernet interfaces (no PPP) and
used SLAAC (not DHCP).  Break any of these two conditions and one is
free to use /64 to end user.

E.g. use DHCP with Ethernet, or use SLAAC with PPP, or use DHCP with PPP
- for each those there's no need to allocate shorter-than-/64 prefixes
to UE-which-are-Routers.

I also agree that local configuration is easier to do for operator if
centralized conf files are used, with DHCP, rather than distributed
files with RA.

But 'IPv6 prefixes with flexible length' doesn't really mean much to me
(no offence :-)

SLAAC doesn't allocate prefixes, so this statement can only request DHCP.

DHCP-PD already allocates prefixes with any length.

I do not understand why this Note is there.

> The address space provided is maintained as an IPv6 address space
                     'provided'? (not 'provisioned', not 'assigned')
> pool available to the PDN connection for DHCPv6 IPv6 prefix requests
                         ^^^^^^^^^^^^^^
This should rather be UE-Router, rather than 'PDN connection', because
the PDN connection does not do any prefix request (the UE-Router does).
  Moreover, the prefixes delegated by DHCP this way are not used at all
on that PDN connection.

> with the exclusion of the IPv6 prefix that is allocated to the PDN
> connection during default bearer establishment as defined in clause
> 5.3.1.2.2.

So, the /64 is 'allocated' to the PDN connection and the other 254 /64s
are 'provided' to the same PDN connection?  This is unclear.

In implementation, the way these prefixes are 'assigned', 'requested',
'advertised' have very precise meanings, and they relate to the ways the
routing tables are constructed (triplets of "prefix-nexthop-interface").
  Rather use these terms from implementation if one wants to avoid
confusion and be understandable.

> The total IPv6 address space available for the PDN connection (UE
> default bearer prefix

'default bearer prefix'?  Earlier it was 'default bearer establishment'.
  So 'default' relates to 'default bearer', not 'default prefix'.  But
before that occurence, on the first phrase, it said 'default /64 prefix'!

Overall we have:
default bearer establishment
default bearer prefix
default /64 prefix

None appears in RFCs I look at.

> and UE PDN connection IPv6 address space pool) shall be possible to
> aggregate into one IPv6 prefix that will represent all IPv6 addresses
> that the UE may use.

What does it mean to 'aggregate'?

Earlier it said "Optionally a single network prefix shorter than the
default /64 prefix may be assigned to a PDN connection [...] the /64
default prefix will be allocated from this network prefix; the remaining
address space from the network prefix can be delegated"

I believe this aggregation happens all the time, no need to request it
with a "shall be possible". It is always automatically possible given
the initial 'shorter prefix, remaining prefix'.

Besides, I believe that if one tries to really understand that word
'aggregation' one may have surprises.

For example, a UE-Router with two 'southbound' interfaces and one 3GPP
interface may need to request two prefixes: one for each southbound
interface.  These two prefixes don't necessarily need to be 'aggregated'
into each other (differ at the 4th leftmost bit!) and they don't even
need to be aggregated with the prefix of the address of the 3GPP
interface (differ at the 4th leftmost bit again).

In one way, all distinct prefixes are aggregated into one another
because they have the same 3 leftmost bit.  In another way two distinct
/64 prefixes can never be aggregated one into another because they
differ at the leftmost 65th bit.

> The UE uses DHCPv6 to request additional IPv6 prefixes (i.e.
> prefixes in addition to the default prefix)

Again - what is a 'default prefix'?  It doesn't appear in relevant RFCs.

> The UE acts as a "Requesting Router"
[...]
> The PDN GW acts as the DHCP server and fulfils the role of a
> "Delegating Router"

But could PDN GW act as a DHCP Relay as well?  It is useful option for
deployments to use a multiplicity of Relays (one per PDN GW?) and one
central DHCP Server rather than a DHCP Server for each PDN GW.

Besides, if we assume that PDN GW obtains its prefixes also using
DHCPv6-PD (implied by the earlier 'PDN GW  obtains the prefix from the
external PDN'), is PDN GW be a Requesting Router as well?

> The PDN GW delegates a prefix excluding the default prefix

How does it 'exclude'?  draft pd-exclude doesn't tell how.

There are many ways to 'exclude' especially when it's not told how.

Excluding a /64 from a /48 results in several prefix_es_ and hence the
above statement is wrong to say PDN GW delegates _a_ prefix.

Given 2001:db8:1:1::/64
and   2001:db8:1::/48,
the 'exclusion' of the former from the latter may result in:

2001:db8:1:0000::/64
2001:db8:1:0002::/64
2001:db8:1:0003::/64
...
2001:db8:1:ffff::/64

or it may result in:
2001:db8:1::/63 if we ignore 0.

> Prefix exclusion procedures shall follow
> draft-ietf-dhc-pd-exclude-00

Sorry it doesn't tell to my reading.

That draft only tells:
> the requesting router has earlier been assigned a
> 2001:db8:dead:beef::/64 prefix by the delegating router, and the
> delegated prefix in the OPTION_IAPREFIX is 2001:db8:dead:bee0::/59.
> In this case, 2001:db8: dead:beef::/64 is a valid prefix to be used
> in the OPTION_PD_EXCLUDE option.

Certainly yes, 2001:db8:dead:beef::/64 is a valid prefix to be used in
the EXCLUDE option, because 'the RR has earlier been assigned a
2001:db8:dead:beef::/64' - it's said right above.  This is always true.

But, what an implementer is interested in is: what prefixes (or single
prefix?) result when 'excluding' 2001:db8:dead:beef::/64 from
2001:db8:dead:bee0::/59?  This draft doesn't tell.

Friendly yours,

Alex