Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Sep 2013 10:19:58 +0200

Hello,

Please allow me to re-issue this, now in relationship with Leaf's draft.

2013/8/19 Tomek Mrugalski <[email-masked]>

> On 12.08.2013 21:21, Bernie Volz (volz) wrote:
> > During the Berlin IETF-87 DHC WG session, it was suggested that we
> > initiate a standards action request to move RFC 3315 (and RFC 3633),
> > which are presently Proposed Standards, to Internet Standard. While we
> > plan to work on a 3315bis which would merge the work, it was pointed out
> > by several people (include our Area Director) that there is technically
> > no need to wait for that to advance the standards.
> >
> > The requirements for advancement are outlined in RFC 2026 and RFC 6410
> > (which removed Draft Standard).
> >
> > Per RFC 6410:
> >
> > The criteria are:
>

[...]

>    (2) There are no errata against the specification that would cause a
> >        new implementation to fail to interoperate with deployed ones.
>

In RFC 3315 DHCPv6-PD there is a questionable use of the term 'provider
edge router.' in a section describing the behaviour of the Relay agent:

14.  Relay agent behavior
>
>    A relay agent forwards messages containing Prefix Delegation options
>    in the same way as described in section 20, "Relay Agent Behavior" of
>    RFC 3315.
>
>    If a delegating router communicates with a requesting router through
>    a relay agent, the delegating router may need a protocol or other
>    out-of-band communication to add routing information for delegated
>    prefixes into the *provider edge router*.
>
>
I wonder whether the Authors actually meant 'Relay Agent' by that 'provider
edge router'. Because otherwise the term doesn't appear elsewhere in the
document.

Also, did the authors of RFC3315 meant that a new protocol is needed
between Server and Relay Agent?  Or did they mean that inserting a routing
table should happen by that 'out-of-band' means (and not 'out-of-band
communication')?

I am asking this because I explore the possibilities of formulating a
problem statement about why DHCPv6-PD breaks when assigning a prefix
through a Relay.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Sep 2013 10:26:27 +0200

[sorry if duplicates]

Hello,

[...]

14.  Relay agent behavior

Alex

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Sep 2013 07:46:22 -0400

Alex...

On Sep 11, 2013, at 4:19 AM 9/11/13, Alexandru Petrescu <[email-masked]> wrote:

> In RFC 3315 DHCPv6-PD there is a questionable use of the term 'provider edge router.' in a section describing the behaviour of the Relay agent:
> 
> 14.  Relay agent behavior
> 
>    prefixes into the 
> provider edge router.
> I wonder whether the Authors actually meant 'Relay Agent' by that 'provider edge router'. Because otherwise the term doesn't appear elsewhere in the document.

(Assuming you meant RFC3633) Yes, s/provider edge router/relay agent/

> 
> Also, did the authors of RFC3315 meant that a new protocol is needed between Server and Relay Agent?  Or did they mean that inserting a routing table should happen by that 'out-of-band' means (and not 'out-of-band communication')?

Not speaking for Ole, I meant that some other means, which might be a protocol, manual configuration, etc., is needed to add routing information into the relay agent.

- Ralph

> 
> I am asking this because I explore the possibilities of formulating a problem statement about why DHCPv6-PD breaks when assigning a prefix through a Relay.
> 
> Alex
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Sep 2013 13:52:38 +0200

Le 11/09/2013 13:46, Ralph Droms a écrit :
>> 2013/8/19 Tomek Mrugalski <[email-masked]> On
>> 12.08.2013 21:21, Bernie Volz (volz) wrote:
>>> During the Berlin IETF-87 DHC WG session, it was suggested that
>>> we initiate a standards action request to move RFC 3315 (and RFC
>>> 3633), which are presently Proposed Standards, to Internet
>>> Standard. While we plan to work on a 3315bis which would merge
>>> the work, it was pointed out by several people (include our Area
>>> Director) that there is technically no need to wait for that to
>>> advance the standards.
>>>
>>> The requirements for advancement are outlined in RFC 2026 and RFC
>>> 6410 (which removed Draft Standard).
>>>
>>> Per RFC 6410:
>>>
>>> The criteria are:
>>
>> [...]
>>
>>> (2) There are no errata against the specification that would
>>> cause a new implementation to fail to interoperate with deployed
>>> ones.
>>
>> In RFC 3315 DHCPv6-PD there is a questionable use of the term
>> 'provider edge router.' in a section describing the behaviour of
>> the Relay agent:
>>
>> 14.  Relay agent behavior
>>
>> A relay agent forwards messages containing Prefix Delegation
>> options in the same way as described in section 20, "Relay Agent
>> Behavior" of RFC 3315.
>>
>> If a delegating router communicates with a requesting router
>> through a relay agent, the delegating router may need a protocol or
>> other out-of-band communication to add routing information for
>> delegated prefixes into the provider edge router.
>>
>> I wonder whether the Authors actually meant 'Relay Agent' by that
>> 'provider edge router'. Because otherwise the term doesn't appear
>> elsewhere in the document.
>

Yes, I meant RFC3633, and yes s/provider edge router/relay agent.

That would make for an errata that one could suggest in the errata site?

>> Also, did the authors of RFC3315 meant that a new protocol is
>> needed between Server and Relay Agent?  Or did they mean that
>> inserting a routing table should happen by that 'out-of-band' means
>> (and not 'out-of-band communication')?
>
> Not speaking for Ole, I meant that some other means, which might be a
> protocol, manual configuration, etc., is needed to add routing
> information into the relay agent.

In that sense I agree with it.  It is thus a problem that is already 
explicit in this RFC.

Alex

>
> - Ralph
>
>>
>> I am asking this because I explore the possibilities of formulating
>> a problem statement about why DHCPv6-PD breaks when assigning a
>> prefix through a Relay.
>>
>> Alex _______________________________________________ dhcwg mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Sep 2013 14:04:20 +0200

Alexandru,

> That would make for an errata that one could suggest in the errata site?

I'm not sure I see what difference it would make?

> In that sense I agree with it.  It is thus a problem that is already explicit in this RFC.

everyone does this with snooping today, but that's not covered by any RFC.
the closest we got to exploring the options was in http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Sep 2013 14:10:37 +0200

> I'm not sure I see what difference it would make?

Help others like me to understand the text?

The term 'provider edge router' means something to this protocol?

> the closest we got to exploring the options was in http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00

Noted, thanks.

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 Sep 2013 12:13:49 +0000

And relay agents don't route so why would they technically care about routing? The relay agent is usually co-located on a provider edge router and certainly these components often need to communicate. Thus, I don't think replacing with relay agent would be correct.

- Bernie (from iPad)

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Sep 2013 14:20:32 +0200

Our Relay Agents all route.

We are not a provider.  Our edge network is itself made of a few other 
smaller Access Networks, for mobility experimentation.

Alex

Le 11/09/2013 14:13, Bernie Volz (volz) a écrit :
> And relay agents don't route so why would they technically care about
> routing? The relay agent is usually co-located on a provider edge
> router and certainly these components often need to communicate.
> Thus, I don't think replacing with relay agent would be correct.
>
> - Bernie (from iPad)
>
>>>>> In RFC 3315 DHCPv6-PD there is a questionable use of the
>>>>> term 'provider edge router.' in a section describing the
>>>>> behaviour of the Relay agent:
>>>>>
>>>>> 14.  Relay agent behavior
>>>>>
>>>>> options in the same way as described in section 20, "Relay
>>>>> Agent Behavior" of RFC 3315.
>>>>>
>>>>> through a relay agent, the delegating router may need a
>>>>> protocol or other out-of-band communication to add routing
>>>>> information for delegated prefixes into the provider edge
>>>>> router.
>>>>>
>>>>> I wonder whether the Authors actually meant 'Relay Agent' by
>>>>> that 'provider edge router'. Because otherwise the term
>>>>> doesn't appear elsewhere in the document.
>>>>
>>>>> Also, did the authors of RFC3315 meant that a new protocol
>>>>> is needed between Server and Relay Agent?  Or did they mean
>>>>> that inserting a routing table should happen by that
>>>>> 'out-of-band' means (and not 'out-of-band communication')?
>>>>
>>>> Not speaking for Ole, I meant that some other means, which
>>>> might be a protocol, manual configuration, etc., is needed to
>>>> add routing information into the relay agent.
>>>
>> everyone does this with snooping today, but that's not covered by
>> any RFC. the closest we got to exploring the options was in
>> http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00
>>
>> cheers, Ole
>>
>
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Sep 2013 08:24:55 -0400

> And relay agents don't route so why would they technically care about routing? The relay agent is usually co-located on a provider edge router and certainly these components often need to communica…

Bernie, that's absolutely right and mistake I've often made.  More correct would be "provider edge router that implements the relay agent function"

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Sep 2013 08:34:33 -0400

> Our Relay Agents all route.

As Bernie wrote, relay agents don't route.  The piece of network equipment that implements the relay agent routes, and that network equipment *might* also need a route.

One of the issues we talked about in the dhc WG is that, in fact, a route might need to be installed in some equipment that is not on the client-server path.

So, yeah, perhaps s/provider edge router/some network equipment/ or even s/provider edge router/the network/

- Ralph

> 
> We are not a provider.  Our edge network is itself made of a few other smaller Access Networks, for mobility experimentation.
> 
> Alex
>

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 23 Sep 2013 01:57:48 +0800

Ralph > The piece of network equipment that implements the relay agent
routes, and that network equipment *might* also need a route.

On the PE router implementing relay for DHCPv6-PD, it always needs add the
associated route for the CE's network of delegated prefix. 
I can't see *might* here.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ralph Droms
Sent: Wednesday, September 11, 2013 8:35 PM
To: Alexandru Petrescu
Cc: [email-masked]; Ralph Droms; Bernie Volz (volz)
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

> Our Relay Agents all route.

As Bernie wrote, relay agents don't route.  The piece of network equipment
that implements the relay agent routes, and that network equipment *might*
also need a route.

One of the issues we talked about in the dhc WG is that, in fact, a route
might need to be installed in some equipment that is not on the
client-server path.

So, yeah, perhaps s/provider edge router/some network equipment/ or even
s/provider edge router/the network/

- Ralph

>>>>>> through a relay agent, the delegating router may need a protocol 
>>>>>> or other out-of-band communication to add routing information for 
>>>>>> inserting a routing table should happen by that 'out-of-band' 
>>>>>> means (and not 'out-of-band communication')?
>>>>> 
>>>>> Not speaking for Ole, I meant that some other means, which might 
>>>>> be a protocol, manual configuration, etc., is needed to add 
>>>>> routing information into the relay agent.
>>>>

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 23 Sep 2013 01:57:48 +0800

Ole - the closest we got to exploring the options was in
http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00 

I can't find the description on the behavior of DHCPv6 *server* in this
document.

<quote> 
   A prefix delegation deployment consists of Requesting Routers (RR),
   Delegating Routers (DR) and possibly a backend provisioning system
   (see Figure 1).
</quote>

Who is assumed to be the DHCPv6 *server* in this document ?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ole Troan
Sent: Wednesday, September 11, 2013 8:04 PM
To: Alexandru Petrescu
Cc: [email-masked]; Ralph Droms; Bernie Volz (volz)
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

Alexandru,

>>> 'provider edge router.' in a section describing the behaviour of the 
>>> Relay agent:
>>> 
>>> 14.  Relay agent behavior
>>> 
>>> in the same way as described in section 20, "Relay Agent Behavior" 
>>> of RFC 3315.
>>> 
>>> prefixes into the provider edge router.
>>> 

>>> between Server and Relay Agent?  Or did they mean that inserting a 
>>> routing table should happen by that 'out-of-band' means (and not 
>>> 'out-of-band communication')?
>> 
explicit in this RFC.

everyone does this with snooping today, but that's not covered by any RFC.
the closest we got to exploring the options was in
http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 23 Sep 2013 13:43:57 +0200

> Who is assumed to be the DHCPv6 *server* in this document ?

RFC3633 terminology:
  delegating router:  The router that acts as a DHCP server, and is
                       responding to the prefix request.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Sep 2013 13:50:11 +0200

> I can't see *might* here.

I agree with the doubt.  I don't see a might, but rather a must. 
Otherwise it doesn't work.

But maybe I dont understand the word 'might' as a native speaker could 
hear it.

Alex

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 23 Sep 2013 15:55:58 +0200

> But maybe I dont understand the word 'might' as a native speaker could
Relay agent is functionality that can be provided by a piece of
software. You can run it on any box that is connected to more than one
network. Although typically such a box serves as a router, it doesn't
have to.

Ralph speaks about a generic case (any device that runs relay agent
software) and Leaf thinks about specific one (PE router). Hence the
confusion.

Tomek

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Sep 2013 16:58:09 +0200

> network. Although typically such a box serves as a router, it doesn't

You mean a Relay agent which runs on a pure Host (single real interface, 
no additional virtual/real interfaces)?

Even in that case it (or the Router on the same link which is connected 
to the Internet) will need to install a route towards the Requesting 
Router's interface for the delegated prefix.

In all cases, the Relay and other routers on that link MUST install a route.

Whether they do it at allocation time, at ICMP Redirect time, or at 
manual config time - is another matter.

Without that route the whole schmillblick doesn't work.

Alex

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 Sep 2013 18:03:12 +0100

> On Sep 23, 2013, at 12:50 PM, Alexandru Petrescu <[email-masked]> wrote:
> 
> I agree with the doubt.  I don't see a might, but rather a must. Otherwise it doesn't work.
> 
> But maybe I dont understand the word 'might' as a native speaker could hear it.

The PE needs the route, but it might not be the device implementing the DHCPv6 relay...clarifying what I wrote earlier, the device implementing the DHCPv6 relay might not be the PE, which is the device that needs the route.

I understand you have constructed your network so that the PE acts as the relay.  When the dhc WG reviewed the idea previously, it declined to pursue the idea for st least these reasons:
* no guarantee that the relay agent is on the device that needs the route
* no guarantee that the route update messages will be delivered in the right order
* (generalization of the previous point) piggybacking router configuration on device config messages is not a good design
* (corollary to the previous point) there are lots of other ways to configure routing that don't involve a new protocol

- Ralph

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 24 Sep 2013 01:04:06 +0800

> http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00
<quote> @ section 5
5.  Summary
   The backend provisioning system should not be assigned the
   responsibility for the maintenance of the route.  As seen in
   Section 2.1, that approach has significant obstacles without any
   clear benefits.
</quote>

What would the communication mechanism be expected between the backend
provisioning system and the DR (DHCPv6 server) here?

The DR (DHCPv6 server) sounds have all the routing state associated with the
PD prefix. Why do you need introduce the backend provisioning system here if
it is not the DHCPv6 server?

<quote> @ section 5
   If the link layer state can be used to detect the (potential) restart
   of delegating router, the requesting router-based simple
   reconfiguration described in Section 2.3.1 seems to be the best
   choice.
</quote> 

The RR has got the lease of its own PD prefix. If the link (or the
communication) between the RR (DHCPv6 client) and the DR (DHCPv6 server)
lost, than the lease of PD prefix will expire after its valid-lifetime if
the client can't get the Reply from the server. What does the 'best choice'
mean here?

<quote> @ section 5
   When link layer state is not available, there is no clear 'best'
   solution.  The tradeoff seems to be between increasing the complexity
   of the delegation protocol and the delegating router/backend system
   (as described in the lease query cases in Section 2.2.1 and
   Section 2.2.2), decreasing scalability of the system significantly by
   using low lifetimes for configuration (as described in
   Section 2.3.3), or small overhead of the keepalive (as described in
   Section 2.3.2).
</quote>

Is there any communication mechanism between DR (the DHCPv6 server) and the
backend system for the lease query? Dose the DR act as the requestor
(defined in RFC5007) for that lease query? 

Best Regards,
Leaf

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Monday, September 23, 2013 7:44 PM
To: Leaf Yeh
Cc: 'Alexandru Petrescu'; [email-masked]; 'Ralph Droms'; 'Bernie Volz
(volz)'

> I can't find the description on the behavior of DHCPv6 *server* in 
> this document.
> 
> <quote> 

RFC3633 terminology:

cheers,
Ole

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Ole Troan
Behavior"
>>> Not speaking for Ole, I meant that some other means, which might be 
>>> a protocol, manual configuration, etc., is needed to add routing

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 24 Sep 2013 01:15:37 +0800

Ralph >The PE needs the route, but it might not be the device implementing the DHCPv6 relay...clarifying what I wrote earlier, the device implementing the DHCPv6 relay might not be the PE, which is the device that needs the route.
....
Ralph > * no guarantee that the relay agent is on the device that needs the route

The 1st router (always called PE router) always need to implement the relay agent for the scenario with the centralized DHCPv6 server. Otherwise, the client will talk with the relay over (the 1st) router.

Best Regards,
Leaf

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Tuesday, September 24, 2013 1:03 AM
To: Alexandru Petrescu
Cc: Leaf Yeh; [email-masked]; Bernie Volz (volz)
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

>> Ralph > The piece of network equipment that implements the relay 
>> agent routes, and that network equipment *might* also need a route.
>> 
>> On the PE router implementing relay for DHCPv6-PD, it always needs 
>> add the associated route for the CE's network of delegated prefix.

- Ralph

>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Ralph Droms
>> As Bernie wrote, relay agents don't route.  The piece of network 
>> equipment that implements the relay agent routes, and that network 
>> equipment *might* also need a route.
>> 
>> One of the issues we talked about in the dhc WG is that, in fact, a 
>> route might need to be installed in some equipment that is not on the 
>> client-server path.
>> 
>>>> And relay agents don't route so why would they technically care 
>>>> about routing? The relay agent is usually co-located on a provider 
>>>> edge router and certainly these components often need to communicate.
>>>>>>>> 'provider edge router.' in a section describing the behaviour 
>>>>>>>> of the Relay agent:
>>>>>>>> 
>>>>>>>> 14.  Relay agent behavior
>>>>>>>> 
>>>>>>>> information for delegated prefixes into the provider edge router.
>>>>>>>> 
>>>>>>>> that 'provider edge router'. Because otherwise the term doesn't 
>>>>>>>> appear elsewhere in the document.
>>>>>>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 23 Sep 2013 17:28:04 +0000

For RFC 3633:

   requesting router:  The router that acts as a DHCP client and is
                       requesting prefix(es) to be assigned.

And, yes, this is a router. And, yes, it may need to do whatever may be needed to get traffic for the delegated prefix to flow to it (i.e., injecting the route). But this doesn't require any snooping or additional communication.

And, in some environments (such as DOCSIS), the requesting router (RR) may not be the one that injects the route. Reasons for this include:
1. Security. Injecting arbitrary routes is not desired.
2. Scale. Having the RR need to run a routing protocol and keeping it up to the next hop isn't desired.

In this case, a Relay Agent (the CMTS which is both a router and relay agent -- this is the "provider edge router") between the RR and DR (delegating router) does the injection.

So, you can see that "who" does the injection can change based on the network design / requirements / security needs.

Anyway, I've probably lost the original issue and also the subject for this message seems to be a bit incorrect? What exactly are we debating?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Monday, September 23, 2013 1:16 PM
To: 'Ralph Droms'; 'Alexandru Petrescu'
Cc: [email-masked]; Bernie Volz (volz)
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

Best Regards,
Leaf

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Tuesday, September 24, 2013 1:03 AM
To: Alexandru Petrescu
Cc: Leaf Yeh; [email-masked]; Bernie Volz (volz)
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Sep 2013 09:32:36 +0100

On Sep 23, 2013, at 3:58 PM 9/23/13, Alexandru Petrescu <[email-masked]> wrote:

> You mean a Relay agent which runs on a pure Host (single real interface, no additional virtual/real interfaces)?
> 
> Even in that case it (or the Router on the same link which is connected to the Internet) will need to install a route towards the Requesting Router's interface for the delegated prefix.

And there's the exact point of the discussion - if the relay agent is not implemented on the router that needs the route, passing the route in the DHCPv6 message exchange through the relay agent won't get the route to the appropriate router.

> In all cases, the Relay and other routers on that link MUST install a route.

And how does that route get to the other routers?

> 
> Whether they do it at allocation time, at ICMP Redirect time, or at manual config time - is another matter.

I'm not saying the route installation can't be accomplished through DHCPv6.  I think you'll need to address the specific issues I raised in previous e-mail to publish a specification for passing routing information to the appropriate router through a DHCPv6 message exchange with a host.

- Ralph

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Sep 2013 15:30:20 +0200

Le 23/09/2013 19:28, Bernie Volz (volz) a écrit :
> And, yes, this is a router. And, yes, it may need to do whatever may
> be needed to get traffic for the delegated prefix to flow to it
> (i.e., injecting the route). But this doesn't require any snooping or
> additional communication.
>
> And, in some environments (such as DOCSIS), the requesting router
> (RR) may not be the one that injects the route. Reasons for this
> include: 1. Security. Injecting arbitrary routes is not desired. 2.
> Scale. Having the RR need to run a routing protocol and keeping it up
> to the next hop isn't desired.
>
> In this case, a Relay Agent (the CMTS which is both a router and
> relay agent -- this is the "provider edge router") between the RR and
> DR (delegating router) does the injection.
>
> So, you can see that "who" does the injection can change based on the
> network design / requirements / security needs.
>
> Anyway, I've probably lost the original issue and also the subject
> for this message seems to be a bit incorrect? What exactly are we
> debating?

We are debating whether or not errata in RFC 3633 is deemed necessary 
with respect to this: should the text in section 14
of RFC 3633 'DHCPv6-PD' use the term 'Relay' instead of 'provider edge 
router'?

(during the discussion it helps me see better about the problem 
statement of that route injection in presence of Relay functionality 
during PD).

Alex

>
> - Bernie
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Leaf Yeh Sent: Monday,
> September 23, 2013 1:16 PM To: 'Ralph Droms'; 'Alexandru Petrescu'
> Cc: [email-masked]; Bernie Volz (volz) Subject: Re: [dhcwg] Advancing
> RFC 3315 and RFC 3633 to Internet Standard
>
> Ralph >The PE needs the route, but it might not be the device
> implementing the DHCPv6 relay...clarifying what I wrote earlier, the
> device implementing the DHCPv6 relay might not be the PE, which is
> the device that needs the route. .... Ralph > * no guarantee that the
> relay agent is on the device that needs the route
>
> The 1st router (always called PE router) always need to implement the
> relay agent for the scenario with the centralized DHCPv6 server.
> Otherwise, the client will talk with the relay over (the 1st)
> router.
>
>
> Best Regards, Leaf
>
>
>
>
> -----Original Message----- From: Ralph Droms
> [mailto:[email-masked]] Sent: Tuesday, September 24, 2013 1:03
> AM To: Alexandru Petrescu Cc: Leaf Yeh; [email-masked]; Bernie Volz
> (volz) Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to
> Internet Standard
>
>
>
>>> On the PE router implementing relay for DHCPv6-PD, it always
>>> needs add the associated route for the CE's network of delegated
>>> prefix. I can't see *might* here.
>>
> The PE needs the route, but it might not be the device implementing
> the DHCPv6 relay...clarifying what I wrote earlier, the device
> implementing the DHCPv6 relay might not be the PE, which is the
> device that needs the route.
>
> I understand you have constructed your network so that the PE acts as
> the relay.  When the dhc WG reviewed the idea previously, it declined
> to pursue the idea for st least these reasons: * no guarantee that
> the relay agent is on the device that needs the route * no guarantee
> that the route update messages will be delivered in the right order *
> (generalization of the previous point) piggybacking router
> configuration on device config messages is not a good design *
> (corollary to the previous point) there are lots of other ways to
> configure routing that don't involve a new protocol
>
> - Ralph
>
>
>>
>> Alex
>>
>>>
>>>
>>> Best Regards, Leaf
>>>
>>>
>>>
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Ralph Droms Sent:
>>> Wednesday, September 11, 2013 8:35 PM To: Alexandru Petrescu Cc:
>>> [email-masked]; Ralph Droms; Bernie Volz (volz) Subject: Re:
>>> [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard
>>>
>>>
>>> equipment that implements the relay agent routes, and that
>>> network equipment *might* also need a route.
>>>
>>> One of the issues we talked about in the dhc WG is that, in fact,
>>> a route might need to be installed in some equipment that is not
>>> on the client-server path.
>>>
>>> So, yeah, perhaps s/provider edge router/some network equipment/
>>> or even s/provider edge router/the network/
>>>
>>> - Ralph
>>>
>>>>
>>>>> And relay agents don't route so why would they technically
>>>>> care about routing? The relay agent is usually co-located on
>>>>> a provider edge router and certainly these components often
>>>>> need to communicate. Thus, I don't think replacing with relay
>>>>> agent would be correct.
>>>>>
>>>>> - Bernie (from iPad)
>>>>>
>>>>>>>>> In RFC 3315 DHCPv6-PD there is a questionable use of
>>>>>>>>> the term 'provider edge router.' in a section
>>>>>>>>> describing the behaviour of the Relay agent:
>>>>>>>>>
>>>>>>>>> 14.  Relay agent behavior
>>>>>>>>>
>>>>>>>>> A relay agent forwards messages containing Prefix
>>>>>>>>> Delegation options in the same way as described in
>>>>>>>>> section 20, "Relay Agent Behavior" of RFC 3315.
>>>>>>>>>
>>>>>>>>> If a delegating router communicates with a requesting
>>>>>>>>> router through a relay agent, the delegating router
>>>>>>>>> may need a protocol or other out-of-band
>>>>>>>>> communication to add routing information for
>>>>>>>>> I wonder whether the Authors actually meant 'Relay
>>>>>>>>> Agent' by that 'provider edge router'. Because
>>>>>>>>> otherwise the term doesn't appear elsewhere in the
>>>>>>>>> document.
>>>>>>>>
>>>>>>>>> Also, did the authors of RFC3315 meant that a new
>>>>>>>>> protocol is needed between Server and Relay Agent?
>>>>>>>>> Or did they mean that inserting a routing table
>>>>>>>>> should happen by that 'out-of-band' means (and not
>>>>>>>> Not speaking for Ole, I meant that some other means,
>>>>>>>> which might be a protocol, manual configuration, etc.,
>>>>>>>> is needed to add routing information into the relay
>>>>>>>> agent.
>>>>>>>
>>>>>> everyone does this with snooping today, but that's not
>>>>>> covered by any RFC. the closest we got to exploring the
>>>>>> options was in
cheers, Ole
>>>
>>> _______________________________________________ dhcwg mailing
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Sep 2013 15:35:23 +0200

Le 24/09/2013 10:32, Ralph Droms a écrit :
>>>>> Ralph > The piece of network equipment that implements the
>>>>> relay agent routes, and that network equipment *might* also
>>>>> need a route.
>>>>>
>>>>> needs add the associated route for the CE's network of
>>>>> delegated prefix. I can't see *might* here.
>>>>
>>> software. You can run it on any box that is connected to more
>>> than one network. Although typically such a box serves as a
>>> router, it doesn't have to.
>>
>> You mean a Relay agent which runs on a pure Host (single real
>> interface, no additional virtual/real interfaces)?
>>
>> Even in that case it (or the Router on the same link which is
>> connected to the Internet) will need to install a route towards
>> the Requesting Router's interface for the delegated prefix.
>
> And there's the exact point of the discussion - if the relay agent
> is not implemented on the router that needs the route, passing the
> route in the DHCPv6 message exchange through the relay agent won't
> get the route to the appropriate router.
>
>>

They are all on the same link, and one mechanism used to install routes
dynamically is during ICMP Redirect.

>> Whether they do it at allocation time, at ICMP Redirect time, or
>> at manual config time - is another matter.
>
> I'm not saying the route installation can't be accomplished through
> DHCPv6.  I think you'll need to address the specific issues I raised
> in previous e-mail to publish a specification for passing routing
> information to the appropriate router through a DHCPv6 message
> exchange with a host.

Ok, my point is whether or not we could formulate a problem statement
for this: there is a need for a route in the concerned routers, after
the PD operation.  Without that route the communication can't be
established between Hosts configured with an address prefixed by the
delegated prefix.

Alex

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Sep 2013 16:11:43 +0100

> On Sep 24, 2013, at 2:30 PM, Alexandru Petrescu <[email-masked]> wrote:
> 
> We are debating whether or not errata in RFC 3633 is deemed necessary with respect to this: should the text in section 14
> of RFC 3633 'DHCPv6-PD' use the term 'Relay' instead of 'provider edge router'?

OLD:

  provider edge router.

NEW:

   any router through which the requesting router may forward traffic.

- Ralph

> 
> (during the discussion it helps me see better about the problem statement of that route injection in presence of Relay functionality during PD).
> 
> Alex
> 
>> 
>> - Bernie
>>

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 25 Sep 2013 00:00:20 +0800

Ralph > And how does that route get to the other routers?

Alexandru > They are all on the same link, and one mechanism used to install
routes dynamically is during ICMP Redirect.

Are you talking about the following network structure?

 

Only Router-A acts as the DR.

Is this structure important in your mind?

Best Regards,

Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Tuesday, September 24, 2013 9:35 PM
To: Ralph Droms
Cc: [email-masked] WG
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

Le 24/09/2013 10:32, Ralph Droms a écrit :

> On Sep 23, 2013, at 3:58 PM 9/23/13, Alexandru Petrescu 

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

>>>>> agent routes, and that network equipment *might* also need a 

>>>>> route.

>>>> But maybe I dont understand the word 'might' as a native speaker 

>>>> could hear it.

>>> software. You can run it on any box that is connected to more than 

>>> one network. Although typically such a box serves as a router, it 

>>> doesn't have to.

>> connected to the Internet) will need to install a route towards the 

>> Requesting Router's interface for the delegated prefix.

> And there's the exact point of the discussion - if the relay agent is 

> not implemented on the router that needs the route, passing the route 

> in the DHCPv6 message exchange through the relay agent won't get the 

> route to the appropriate router.

>> In all cases, the Relay and other routers on that link MUST install a 

>> route.

> exchange with a host.

Ok, my point is whether or not we could formulate a problem statement for
this: there is a need for a route in the concerned routers, after the PD
operation.  Without that route the communication can't be established
between Hosts configured with an address prefixed by the delegated prefix.

Alex

>>  <mailto:[email-masked]> [email-masked]
<https://www.ietf.org/mailman/listinfo/dhcwg>
https://www.ietf.org/mailman/listinfo/dhcwg

 

dhcwg mailing list

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

 <https://www.ietf.org/mailman/listinfo/dhcwg>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Sep 2013 18:41:26 +0200

Le 24/09/2013 18:00, Leaf Yeh a écrit :
> Alexandru > They are all on the same link, and one mechanism used to
> install routes dynamically is during ICMP Redirect.
>

In that figure, Router-A has an additional link towards the Internet. 
And Router-B runs the Relay software, and has only one link - as pictured.

There is no term 'Delegated Router' (sorry no offence :-).  There is a 
'Delegating Router' and that should be the DHCPServer situated deep in 
the infrastructure (please draw it).

Also, the 'CE Router/RR' has an additional link to other Hosts which use 
the delegated prefix to configure addresses for selves.  It's the local 
LAN, of which that RR is in charge of.

In that case - yes, I think such a figure is good for some deployments 
for reasons I could describe.

Yours,

Alex

>
> mailbox:///C:/data/imap-cea-start7sept2011/ietf.sbd/ietf-dhcwg?number=56814925&header=quotebody&part=1.2&filename=image001.png
>
> From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Cc: [email-masked] <mailto:[email-masked]> WG
>> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>
>
>>> Le 23/09/2013 15:55, Tomek Mrugalski aécrit :
>
>>>>> Le 22/09/2013 19:57, Leaf Yeh aécrit :
>
>>>[email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
>

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Sep 2013 21:43:56 +0100

> dynamically is during ICMP Redirect.

According to RFC 4861, sec. 8.2, routers ignore ICMPv6 Redirect messages:

   A router MUST NOT update its routing tables upon receipt of a
   Redirect.

I don't recall if that text is updated by subsequent RFCs.

> established between Hosts configured with an address prefixed by the

I agree that there is a need for the route to exist and an appropriate problem statement could be formulated.

- Ralph

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 25 Sep 2013 14:43:27 +0800

I suppose the network scenario on this topic, i.e. routing issue associated
with the DHCPv6-PD, is the same as that of
ietf-dhc-dhcpv6-agentopt-delegate-04.

Draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 has 2 Network Architectures for the
scenario discussion. One is as follows

             +------+------+  DHCPv6 Server
             |    DHCPv6   |  (e.g. Binding entry:
             |    Server   |        Relay=nfi-GUA#2,
             |             |        Interface-ID=cfi#3,
             +------+------+        Prefix Pool=2001:db8:1200::/40)
                    |
           _________|_________
          /                   \
         |  ISP Core Network   |
          \___________________/
                    |
                    |
                    |  Network-facing interface
                    |         (e.g. IPv6 address=nfi-GUA#2)
             +------+------+
             |   Provider  |
             |     Edge    |  DHCPv6 Relay Agent, DHCPv6 Requestor
             |    Router   |
             +------+------+
                    |  Customer-facing interface
                    |         (e.g. Interface-ID=cfi#3)
                    |               Prefix Pool=2001:db8:1200::/40)
           _________|_________
          /                   \
         |   Access Network    |
          \___________________/
                    |
                    |
             +------+------+
             |   Customer  |  DHCPv6 Client
             |     Edge    |  DHCPv6-PD Requesting Router
             |    Router   |  (e.g. customer network
             +------+------+        =2001:db8:1234:5600:/56)
                    |
           _________|_________
          /                   \
         |  Customer Network   |
          \___________________/

Best Regards,
Leaf

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2013 12:41 AM
To: Leaf Yeh
Cc: 'Ralph Droms'; [email-masked]
Subject: Re: discussion about PD-Relay-route

There is no term 'Delegated Router' (sorry no offence :-).  There is a
'Delegating Router' and that should be the DHCPServer situated deep in the
infrastructure (please draw it).

Also, the 'CE Router/RR' has an additional link to other Hosts which use the
delegated prefix to configure addresses for selves.  It's the local LAN, of
which that RR is in charge of.

In that case - yes, I think such a figure is good for some deployments for
reasons I could describe.

Yours,

Alex

>
> mailbox:///C:/data/imap-cea-start7sept2011/ietf.sbd/ietf-dhcwg?number=
> 56814925&header=quotebody&part=1.2&filename=image001.png
>
>>>>>> needs
> They are all on the same link, and one mechanism used to install

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Sep 2013 13:27:14 +0200

Hi Leaf,

I am not sure there exists a term 'DHCPv6 Requestor' as depicted below.

Also, the Relay Agent is separated from the Requesting Router by at most 
1-hop.  The Relay Agent and the RR must be Neighbors in terms of ND, I 
think.  But the figure shows one Access Network, which I dont know what 
you mean.  If you mean a point-to-point link (like PPP protocol) then I 
agree with it, because it is just 1-hop.  But if you mean a complex 
graphs of IP routers and many hops then I don't know whether it works.

But I agree with the figure overall, it is one potential deployment.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Sep 2013 13:36:59 +0200

> I don't recall if that text is updated by subsequent RFCs.

I don't know either whether subsequent RFCs update it, or whether linux 
has knobs allowing that - one should check.

And, what I meant is not a necessarily a Router but maybe a Host DHCPRelay:
                         ________ ----------
                        |        |DHCPServer|
                       ...        ----------
                        |
     ----------     ---------
    | Host     |   | Access  |
    | DHCPRelay|   | Router  |
     ----------     ---------
         |              |
     ----+--------------+
         |
     ----------     ----
    |Requesting|   | PC |
    | Router   |   |    |
     ----------     ----
         |            |
     ----+------------+--

After the PD phase, and after the assumed route insertion in Access 
Router, the Host DHCPRelay would get an ICMPRedirect from the Access 
Router whenever wanting to talk to PC.  The route it installs is for the 
Delegated Prefix.

(the topology above has some advantages in terms of rapid deployment of 
DHCPv6 in a hostpot network).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Sep 2013 14:08:27 +0200

Here is a topology that is relevant for smartphones doing tethering (see 
the alternative 64share draft) and for vehicles doing Mobile Routers, 
and for 3GPP DHCPv6 Prefix Delegation.

              +------+------+  DHCPv6 Server
              |    DHCPv6   |
              |    Server   |
              |             |
              +------+------+
                     |
            _________|_________
           /                   \
          |  ISP Core Network   |
           \___________________/
                     |
                     |
                     |
                     |
              +------+------+
              |             |
              |    Access   |  DHCPv6 Relay Agent
              |    Router   |
              +------+------+
                     |        Cellular
                     |        Air Interface
                     |
            _________|_________
            ___________________
                     |
                     |
              +------+------+
              |    Mobile   |  DHCPv6 Client
              |    Router,  |  DHCPv6-PD Requesting Router
              |or smartphone|
              +------+------+
                     |
            _________|_________
            ___________________  WiFi
                     |
                     |
              +------+------+
              |   tablet    |
              +-------------+

Yours,

Alex

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 26 Sep 2013 01:34:36 +0800

Alex - I am not sure there exists a term 'DHCPv6 Requestor' as depicted
below.

You can get the definition of DHCPv6 Requestor in the section 2 of
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03#section-
2 . That is 
'A node defined in [RFC5007] that acts as the leasequery client.' 
http://tools.ietf.org/html/rfc5007#section-2 

Alex - But the figure shows one Access Network, which I dont know what you
mean.

Access Network is always regards as layer-2 network, eg. PPPoE or IPoE. 

Per BBF TR-177, the definition of Access Network is 
'The Access Network encompasses the elements of the network from the
Network Interface Device (NID) at the customer premises to a Broadband
Network Gateway. This network typically includes one or more types of
Access Node and may include an Ethernet aggregation function.' 
@ section 2.3. of
http://www.broadband-forum.org/technical/download/TR-177.pdf .

Best Regards,
Leaf

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2013 7:27 PM
To: Leaf Yeh
Cc: 'Ralph Droms'; [email-masked]
Subject: Re: discussion about PD-Relay-route

Hi Leaf,

Also, the Relay Agent is separated from the Requesting Router by at most
1-hop.  The Relay Agent and the RR must be Neighbors in terms of ND, I
think.  But the figure shows one Access Network, which I dont know what you
mean.  If you mean a point-to-point link (like PPP protocol) then I agree
with it, because it is just 1-hop.  But if you mean a complex graphs of IP
routers and many hops then I don't know whether it works.

Alex

Le 25/09/2013 08:43, Leaf Yeh a écrit :
> I suppose the network scenario on this topic, i.e. routing issue 
> associated with the DHCPv6-PD, is the same as that of 
> Draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 has 2 Network Architectures 
> for the scenario discussion. One is as follows
>
> Also, the 'CE Router/RR' has an additional link to other Hosts which 
> use the delegated prefix to configure addresses for selves.  It's the 
> local LAN, of which that RR is in charge of.
>
>> mailbox:///C:/data/imap-cea-start7sept2011/ietf.sbd/ietf-dhcwg?number
>> = 56814925&header=quotebody&part=1.2&filename=image001.png
>>
>>> is

---

From: Ralph Droms <[email-masked]>
Date: Wed, 25 Sep 2013 20:17:38 +0100

On Sep 25, 2013, at 12:36 PM 9/25/13, Alexandru Petrescu <[email-masked]> wrote:

> I don't know either whether subsequent RFCs update it, or whether linux has knobs allowing that - one should check.
> 
> After the PD phase, and after the assumed route insertion in Access Router, the Host DHCPRelay would get an ICMPRedirect from the Access Router whenever wanting to talk to PC.  The route it installs is for the Delegated Prefix.

The "Host DHCPRelay" has to be on the same link with the PC.

How does the Access Router know the route through the RR to the PC?  I thought that was the information that needs to be installed on the Access Router.

- Ralph

> 
> (the topology above has some advantages in terms of rapid deployment of DHCPv6 in a hostpot network).
> 
> Alex
> 
>> 
>>>

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 25 Sep 2013 21:40:00 +0200

> I am not sure there exists a term 'DHCPv6 Requestor' as depicted below.
This term is defined in RFC5007. DHCPv6 Requestor is an entity that
sends leasequery requests and processes leasequery responses. While
typically that is a part of relay agent software that recover client
info after relay reboot, it doesn't have to be. From the protocol
perspective, a requestor is a separate entity.

There are stand-alone implementations that offer leasequery requestor
functionality, without being relays.

Tomek

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Sep 2013 09:16:29 +0200

> functionality, without being relays.

Thanks for the explanation!

This term Requestor makes sense in that context of requesting a 
leasequery and maybe being on a Relay.

Until now I always talked Requesting Router as being the Client 
requesting a Prefix, and safely different than the Relay.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Sep 2013 09:21:26 +0200

Le 25/09/2013 21:17, Ralph Droms a écrit :
>> Router, the Host DHCPRelay would get an ICMPRedirect from the
>> Access Router whenever wanting to talk to PC.  The route it
>> installs is for the Delegated Prefix.
>

Not sure about that.  The PC uses RA to autoconfigure an address and 
default route, whereas the Requesting Router uses DHCP to get a prefix.

> How does the Access Router know the route through the RR to the PC?
> I thought that was the information that needs to be installed on the
> Access Router.

Right.  If the DHCPRelay is a different machine than the Access Router 
(as pictured abve) then indeed there is little chance that AR knows how 
to install a route.  Assuming it had a means to do it, later on it could 
do ICMP Redirect to the Host DHCPRelay.

But yes, there is a problem on how the AR dyncamically installs a route 
for the RequestingRouter, after the prefix allocation.  TO install that 
it needs 3 things: the trigger of the moment to do it, the value of the 
prefix, and the value of the address of the Requesting Router.

Alex