Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 08 Apr 2013 14:32:56 +0200

On 24.03.2013 21:25, Bernie Volz (volz) wrote:
> Folks, the authors of draft-ietf-dhc-dhcpv6-prefix-pool-opt-02
> <http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-02>
> feel it's ready for a WGLC.  There's been discussion and comment
> already, but more eyes on this work are definitely needed to advance it.
> 
> Please review the draft and indicate whether or not you feel it is ready
> to be published.  We have been getting very anemic responses to working
> group messages recently.   Your response matters, so please do respond.
> 
> Tomek and I will evaluate consensus after April 8, 2013.
Today is the last day of this WGLC and the response has been abysmal for
now.

Consider this mail a last reminder. Bernie and I will assess the results
tomorrow. So far it seems that will be an easy decision.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Apr 2013 12:40:34 +0000

> Today is the last day of this WGLC and the response has been abysmal for

This is a bit frustrating—I think the problem that the prefix pool option is addressing is a real problem, but it's so leading edge that I don't think a lot of people have really thought about it.   I think it's a problem that we ought to solve, but if nobody is willing to think about it, it's questionable that it's a good idea for the working group to push the solution.

How many people have actually reviewed the draft at this point and understand the problem it's trying to solve?

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 08 Apr 2013 15:38:55 +0200

On 08.04.2013 14:40, Ted Lemon wrote:
>> Today is the last day of this WGLC and the response has been 
>> abysmal for now.
> 
> This is a bit frustrating—I think the problem that the prefix pool 
> option is addressing is a real problem, but it's so leading edge
> that I don't think a lot of people have really thought about it.   I
> think it's a problem that we ought to solve, but if nobody is willing
> to think about it, it's questionable that it's a good idea for the 
> working group to push the solution.
> 
> How many people have actually reviewed the draft at this point and 
> understand the problem it's trying to solve?
I did review it (I think twice - first when it was individual draft and
later when it was adopted). I've posted couple comments on it some time
ago, but my understanding is that there are 2 outstanding issues that
cannot be easily solved:

Issue 1) this draft allows really stupid things, for example: you can
release (or stop aggregating) prefix-pool when responding to REQUEST and
you can allocate (or rather aggregate) when responding to RELEASE

Issue 2) Take this scenario: the PD for your last client connected
through the relay expires (rather than is being released). Your relay
will get stuck with outdated info, because there is no other DHCP
traffic that server can piggyback on. You could argue that leasequery
can help here, but how often would the relay do the query? This may
introduce non-trivial amount of extra traffic for the server to process.

So to answer your question: I *think* I understand the problem, I just
don't have enough experience in managing ISP networks to say whether
this is the right solution to the problem or not. That's why I haven't
expressed my support here. It is not that I'm opposing. I will count
myself as "abstain".

I think the biggest issue here is a lack of support. There's really
nobody saying "yes, I support this work moving forward". Gang sent some
comments, but he didn't state his support clearly. Even you are saying
that this is important problem and it needs to be solved, but you didn't
say "this is the solution I want" or "I support this work".

On a related note, there's a question in doc write-up:

  (9) How solid is the WG consensus behind this document? Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with it?

As a chair, I wouldn't know how to answer it if we decided to somehow
continue forward with this document. So far it seems there's no
consensus, and chairs even can't say that there's a strong concurrence
of a few individuals, because that "a few" would be just a subset of
co-authors: Leaf and Ted.

There are other smaller issues as well: security considerations is
really empty, ipv6-prefix field length is not precisely defined, this
draft talks about leasequery, but does not clearly define requestor
behavior (I know that requestor in most cases is part of a relay, but
from protocol perspective these are separate entities), this draft
repeats normative language from RFC3315 (e.g. "The relay agent SHOULD
include the Interface ID option"), it is not idnits clean etc.

I did not had enough time to thoroughly review this draft, so I haven't
posted my review of -02. Some of the issues were reported earlier, but
they are still not resolved.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Apr 2013 13:52:50 +0000

I think those are very good comments; perhaps we can work with the author to address them... :)

---

From: Jyrki Soini <[email-masked]>
Date: Mon, 08 Apr 2013 17:29:35 +0300

> How many people have actually reviewed the draft at this point and understand the problem it's trying to solve?

This mechanism is needed. I read the draft and agree with the approach.

There is one issue, that could be clarified, IMHO: What is the relation
between prefix-pool and PE router customer facing interface?

Is there one-to-one mapping between prefix-pool and customer facing
interface?

Can the same prefix-pool be shared with multiple customer facing
interfaces? In this case what happens if customer lease from the
original CFI#1 is released, but other leases are still active.
And further, if CFI#1 later receives a lease from another prefix-pool.

Can the customer facing interface share multiple prefix-pools?

Is many-to-many relation possible?

--
Jyrki

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 9 Apr 2013 00:12:28 +0800

Hi Jyrki,

Thanks for your review & comments.

Jyrki - There is one issue, that could be clarified, IMHO: What is the relation between prefix-pool and PE router customer facing interface? Is there one-to-one mapping between prefix-pool and customer facing interface?

In Fig.2 (or use case 2) of the draft (OPTION_PREFIX_POOL), the prefix pool is associated with the CFI-Customer facing interface on PE. The server is responsible to keep the binding (or mapping ) between the prefix pool & the associated CFI of the PE. 

Jyrki - Can the same prefix-pool be shared with multiple customer facing interfaces? In this case what happens if customer lease from the original CFI#1 is released, but other leases are still active.

In Fig.1 (or use case 1) of the draft, the prefix pool is associated with the whole PE, sharing with all CFIs. The server is responsible to keep the binding (or mapping ) between the prefix pool & the associated PE.

Jyrki - And further, if CFI#1 later receives a lease from another prefix-pool. Can the customer facing interface share multiple prefix-pools?
 
The draft supports the case when multiple prefix pools are associated with the same CFI.

Jyrki - Is many-to-many relation possible?

Still not quite sure whether it is necessary in the real address planning & deployment?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jyrki Soini
Sent: Monday, April 08, 2013 10:30 PM
To: Ted Lemon; Tomek Mrugalski
Cc: <[email-masked]>
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013

On 8.4.2013 15:40, Ted Lemon wrote:
>> Today is the last day of this WGLC and the response has been abysmal 
>> for now.
> 

There is one issue, that could be clarified, IMHO: What is the relation between prefix-pool and PE router customer facing interface?

Is there one-to-one mapping between prefix-pool and customer facing interface?

Can the same prefix-pool be shared with multiple customer facing interfaces? In this case what happens if customer lease from the original CFI#1 is released, but other leases are still active.
And further, if CFI#1 later receives a lease from another prefix-pool.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Apr 2013 16:40:36 +0000

(WG hat co-chair off.)

This document seems to be about avoiding having to manually configure the aggregate prefix at the "Provider Edge Router"?

My issue with this is that there is still other configuration that needs to be configured - such as the DHCPv6 server's address, the link-address or other "identifying" information to know which prefix(es) are in play, etc.

Yes, there might be deployments where using multicast addressing (as per RFC 3315) and having the DHCPv6 server allocate a prefix for the first time it detects the provider edge router, could be done - is this likely?

So, while this document provides for some more auto-configuration, is it really worth it? 

Also, I have concerns about what might happen if the prefix-pool is ::/0 or similarly misconfigured. I suppose this is no worse than the security issues with PD in general but it should be mentioned in the security considerations. There should also be some requirements that the pool contain the delegated prefix (though that of course doesn't solve the ::/0 issue since everything is contained in that).

In the end, I am on the fence with the need for this as I see it as only a small part of the router auto-configuration issue.

If there were people that are eager to implement it (or might already have in some form), I'd could be swayed.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Monday, April 08, 2013 9:39 AM
To: Ted Lemon
Cc: <[email-masked]>
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013

On 08.04.2013 14:40, Ted Lemon wrote:
> This is a bit frustrating-I think the problem that the prefix pool 
I did review it (I think twice - first when it was individual draft and later when it was adopted). I've posted couple comments on it some time ago, but my understanding is that there are 2 outstanding issues that cannot be easily solved:

Issue 1) this draft allows really stupid things, for example: you can release (or stop aggregating) prefix-pool when responding to REQUEST and you can allocate (or rather aggregate) when responding to RELEASE

Issue 2) Take this scenario: the PD for your last client connected through the relay expires (rather than is being released). Your relay will get stuck with outdated info, because there is no other DHCP traffic that server can piggyback on. You could argue that leasequery can help here, but how often would the relay do the query? This may introduce non-trivial amount of extra traffic for the server to process.

So to answer your question: I *think* I understand the problem, I just don't have enough experience in managing ISP networks to say whether this is the right solution to the problem or not. That's why I haven't expressed my support here. It is not that I'm opposing. I will count myself as "abstain".

I think the biggest issue here is a lack of support. There's really nobody saying "yes, I support this work moving forward". Gang sent some comments, but he didn't state his support clearly. Even you are saying that this is important problem and it needs to be solved, but you didn't say "this is the solution I want" or "I support this work".

As a chair, I wouldn't know how to answer it if we decided to somehow continue forward with this document. So far it seems there's no consensus, and chairs even can't say that there's a strong concurrence of a few individuals, because that "a few" would be just a subset of
co-authors: Leaf and Ted.

There are other smaller issues as well: security considerations is really empty, ipv6-prefix field length is not precisely defined, this draft talks about leasequery, but does not clearly define requestor behavior (I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities), this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it is not idnits clean etc.

I did not had enough time to thoroughly review this draft, so I haven't posted my review of -02. Some of the issues were reported earlier, but they are still not resolved.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Apr 2013 17:00:09 +0000

> My issue with this is that there is still other configuration that needs to be configured - such as the DHCPv6 server's address, the link-address or other "identifying" information to know which pr…

Okay, but these all seem like things that are much less dynamic than prefixes.

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 9 Apr 2013 01:31:36 +0800

Tomek - Issue 1) this draft allows really stupid things, for example: you
can release (or stop aggregating) prefix-pool when responding to REQUEST and
you can allocate (or rather aggregate) when responding to RELEASE

Clarification - The key (or permit) of the above mechanism (or behavior) is
that OPTION_PREFIX_POOL try to support the 'real-time' setting (or
aggregation policy) change by the administrator. 
Or do you want to simplify this mechanism?

Tomek - Issue 2) Take this scenario: the PD for your last client connected
through the relay expires (rather than is being released). Your relay will
get stuck with outdated info, because there is no other DHCP traffic that
server can piggyback on. You could argue that leasequery can help here, but
how often would the relay do the query? This may introduce non-trivial
amount of extra traffic for the server to process.

Clarification - The draft provide the mechanism that the relay can
'automatically withdraw the aggregation route' per its own table for
tracking the status of the prefix pools if the PE needs the immediate 'sync'
on those status. 
<quote>
   The PE router acting as the relay agent MAY set up a table for the
   lease or status of the prefix pools on it according to the leases of
   the delegated customer prefixes within the prefix pools.  The lease
   of the prefix pool SHOULD dynamically set to be the maximum lease of
   the delegated customer prefix within it.  If there is no route entry
   directing to the customer network within the aggregation route
   associated with the prefix pool or the lease of prefix pool runs out,
   the PE router acting as the relay agent SHOULD automatically withdraw
   the aggregation route.
</quote>
Or do you want to simplify this mechanism?

Tomek - So to answer your question: I *think* I understand the problem, I
just don't have enough experience in managing ISP networks to say whether
this is the right solution to the problem or not. That's why I haven't
expressed my support here. It is not that I'm opposing. I will count myself
as "abstain".

Let's stimulate more discussions on it.

Tomek - There are other smaller issues as well: security considerations is
really empty, 

Any more detailed review comments or suggested text on it?

Tomek - ipv6-prefix field length is not precisely defined, 

Not quite sure about the issue?
<quote>
pfx-pool-len:   Length for the prefix pool in Bits
   ipv6-prefix:    IPv6 prefix of the prefix pool, which is up to 16
                   octets in length. Bits outsides of the
                   pfx-pool-len, if included, MUST be zero.
</quote>

Tomek - this draft talks about leasequery, but does not clearly define
requestor behavior (I know that requestor in most cases is part of a relay,
but from protocol perspective these are separate entities), 

Do you want a separate section on the 'requestor behavior'?

Tomek - this draft repeats normative language from RFC3315 (e.g. "The relay
agent SHOULD include the Interface ID option"), it is not idnits clean etc.

Not quite sure about the issue? Sounds not difficult to fix it?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tomek Mrugalski
Sent: Monday, April 08, 2013 9:39 PM
To: Ted Lemon
Cc: <[email-masked]>
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

I did review it (I think twice - first when it was individual draft and
later when it was adopted). I've posted couple comments on it some time ago,
but my understanding is that there are 2 outstanding issues that cannot be
easily solved:

Issue 1) this draft allows really stupid things, for example: you can
release (or stop aggregating) prefix-pool when responding to REQUEST and you
can allocate (or rather aggregate) when responding to RELEASE

Issue 2) Take this scenario: the PD for your last client connected through
the relay expires (rather than is being released). Your relay will get stuck
with outdated info, because there is no other DHCP traffic that server can
piggyback on. You could argue that leasequery can help here, but how often
would the relay do the query? This may introduce non-trivial amount of extra
traffic for the server to process.

So to answer your question: I *think* I understand the problem, I just don't
have enough experience in managing ISP networks to say whether this is the
right solution to the problem or not. That's why I haven't expressed my
support here. It is not that I'm opposing. I will count myself as "abstain".

I think the biggest issue here is a lack of support. There's really nobody
saying "yes, I support this work moving forward". Gang sent some comments,
but he didn't state his support clearly. Even you are saying that this is
important problem and it needs to be solved, but you didn't say "this is the
solution I want" or "I support this work".

As a chair, I wouldn't know how to answer it if we decided to somehow
continue forward with this document. So far it seems there's no consensus,
and chairs even can't say that there's a strong concurrence of a few
individuals, because that "a few" would be just a subset of
co-authors: Leaf and Ted.

There are other smaller issues as well: security considerations is really
empty, ipv6-prefix field length is not precisely defined, this draft talks
about leasequery, but does not clearly define requestor behavior (I know
that requestor in most cases is part of a relay, but from protocol
perspective these are separate entities), this draft repeats normative
language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID
option"), it is not idnits clean etc.

I did not had enough time to thoroughly review this draft, so I haven't
posted my review of -02. Some of the issues were reported earlier, but they
are still not resolved.

Tomek

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 9 Apr 2013 02:01:53 +0800

Thanks for the co-chair's review again.

BV>My issue with this is that there is still other configuration that needs
to be configured - such as the DHCPv6 server's address, the link-address or
other "identifying" information to know which prefix(es) are in play, etc.

DHCPv6 server's address always sounds the same ones in the same
administrative domain.
Link-address of relay sounds not always necessary in the un-numbered access
network.
Identifying" information sounds Interface ID in this draft, which is
associated with the device.
Right?

BV>Also, I have concerns about what might happen if the prefix-pool is ::/0
or similarly misconfigured. I suppose this is no worse than the security
issues with PD in general but it should be mentioned in the security
considerations. 

I guess the automatic mechanism sounds a little safer than the manual
configuration. :-)
Any suggested text on the 'security consideration'?

BV>There should also be some requirements that the pool contain the
delegated prefix (though that of course doesn't solve the ::/0 issue since
everything is contained in that).

<quote>
Note that these prefix pools SHOULD not
   overlay, and the delegated customer prefix is only from one prefix
   pool.
</quote>
Text enough?

BV>If there were people that are eager to implement it (or might already
have in some form), I'd could be swayed.

I am eager to wait for your boat swayed. :-)

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Volz (volz)
Sent: Tuesday, April 09, 2013 12:41 AM
To: <[email-masked]>
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

(WG hat co-chair off.)

This document seems to be about avoiding having to manually configure the
aggregate prefix at the "Provider Edge Router"?

My issue with this is that there is still other configuration that needs to
be configured - such as the DHCPv6 server's address, the link-address or
other "identifying" information to know which prefix(es) are in play, etc.

Yes, there might be deployments where using multicast addressing (as per RFC
3315) and having the DHCPv6 server allocate a prefix for the first time it
detects the provider edge router, could be done - is this likely?

So, while this document provides for some more auto-configuration, is it
really worth it? 

Also, I have concerns about what might happen if the prefix-pool is ::/0 or
similarly misconfigured. I suppose this is no worse than the security issues
with PD in general but it should be mentioned in the security
considerations. There should also be some requirements that the pool contain
the delegated prefix (though that of course doesn't solve the ::/0 issue
since everything is contained in that).

In the end, I am on the fence with the need for this as I see it as only a
small part of the router auto-configuration issue.

If there were people that are eager to implement it (or might already have
in some form), I'd could be swayed.

- Bernie

-----Original Message-----

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Apr 2013 20:35:28 +0000

<quote>

The issue here is that if pfx-pool-len is 60, I can provide 0-16 octets of ipv6-prefix (or depending on how you interpret 8-16 octets).

draft-ietf-dhc-option-guidelines-10 has:

   option-length is set to 1 + length of the IPv6 prefix. prefix6-len is
   one octet long and specifies the length in bits of the IPv6 prefix.
   Typically allowed values are 0 to 128.

   ipv6-prefix field is a variable length field that specifies the IPv6
   prefix.  This field is padded with zeros up to the nearest octet
   boundary when prefix6-len is not divisible by 8.

Probably still not the best. I think we want to have the ipv6-prefix field to contain only <prefix+7/8> octets. So, for a 60, we would want it to have 8 octets, not more or less?

This is something we should clear up (also in draft-ietf-dhc-option-guidelines).

The processing might be to initialize 16-octet buffer to all 0's, copy the ipv6-prefix octets (up to 16) into that buffer. The resulting value is the prefix.  This would work and even allow the ipv6-prefix to be LESS than the prefix length when the bits are 0 (such as if 2001::/60 is sent, really only the first 2 octets are needed).

Or, do we want to be more explicit and say that the size of ipv6-prefix always should be <prefix length + 7/8> octets.

Note that this makes a big difference when this information is encoded as a 'structured' option (where additional data may follow). It is less of an issue when this is the only field that is 'variable'. (Note that if we require the <prefix length +7/8> octets, I would really declare this NOT to be variable length as there is a length.)

I also fear if we are not clear, we may end up with implementations that fail to interoperate.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Monday, April 08, 2013 1:32 PM
To: 'Tomek Mrugalski'; 'Ted Lemon'
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013

Tomek - Issue 1) this draft allows really stupid things, for example: you can release (or stop aggregating) prefix-pool when responding to REQUEST and you can allocate (or rather aggregate) when responding to RELEASE

Clarification - The key (or permit) of the above mechanism (or behavior) is that OPTION_PREFIX_POOL try to support the 'real-time' setting (or aggregation policy) change by the administrator. 
Or do you want to simplify this mechanism?

Tomek - Issue 2) Take this scenario: the PD for your last client connected through the relay expires (rather than is being released). Your relay will get stuck with outdated info, because there is no other DHCP traffic that server can piggyback on. You could argue that leasequery can help here, but how often would the relay do the query? This may introduce non-trivial amount of extra traffic for the server to process.

Clarification - The draft provide the mechanism that the relay can 'automatically withdraw the aggregation route' per its own table for tracking the status of the prefix pools if the PE needs the immediate 'sync'
on those status. 
<quote>

Tomek - So to answer your question: I *think* I understand the problem, I just don't have enough experience in managing ISP networks to say whether this is the right solution to the problem or not. That's why I haven't expressed my support here. It is not that I'm opposing. I will count myself as "abstain".

Tomek - There are other smaller issues as well: security considerations is really empty, 

Tomek - this draft talks about leasequery, but does not clearly define requestor behavior (I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities), 

Tomek - this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it is not idnits clean etc.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Monday, April 08, 2013 9:39 PM
To: Ted Lemon
Cc: <[email-masked]>
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Apr 2013 15:19:40 +0200

> Or do you want to simplify this mechanism?
No, the mechanism is more or less ok as it is now. What I'd like to see
is a clarification about status. Something along the lines "Under normal
circumstances the Status field should have value Active when responding
to any client messages, except release and the status should have value
Released only when responding to the Release message sent by the last
active client connected via specific relay. Those recommendation may not
apply if the server configuration has changed".

> Or do you want to simplify this mechanism?
I must have missed that part. Ok, that makes sense. This also implies
that the relays need to to deep packet inspection and parse IA_PD in
relayed responses, but I suppose relays in this deployment scenario do
this anyway, right?

> Any more detailed review comments or suggested text on it?
Come on, there are some easy attack vectors here. What if the server
sends out ::/0 in PREFIX_POOL option? Your relay will hijack the whole
network? This means that if your DHCPv6 server is compromised you can
start controlling (to some degree) traffic in your whole network.

>                    pfx-pool-len, if included, MUST be zero.
Bernie had this concern and I tend to agree with him. For example you
want to convey 2000:db8::/32 prefix. I can send an option with
pfx-pool-len equal to 32, but the ipv6-prefix containing all 16 bytes.
That option would be still conformant to this draft. The updated
option-guidelines-11 draft says (or rather ought to say, but the text is
not as clear as it should be) that the length of ipv6-prefix should be:

floor( (prefix-len + 7)/8 )

> Do you want a separate section on the 'requestor behavior'?
Yes. Please split actions taken by requestor into separate section. It
can be subsection 5.1 if you like to.

> Not quite sure about the issue? Sounds not difficult to fix it?
I didn't say that it is difficult to fix. My understanding is that
documents that reach WGLC phase are expected to be idnits clean, unless
there are good reasons for them to not be. When sending a draft to IESG
that do not pass idnits, it is likely to get an brief response "please
fix idnits" and nothing else. It sometimes takes a lot of time before
IESG looks at such a draft again.

Tomek

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 12 Apr 2013 11:33:05 +0800

I think the text in the draft (OPTION_PREFIX_POOL) sounds not wrong yet. For
the further clarification complied with
I-D.draft-ietf-dhc-option-guidelines, how about update the explanation of
'ipv6-prefix' in OPTION_PREFIX_POOL as follows?

" ipv6-prefix:    IPv6 prefix of the prefix pool, which is
floor((pfx-pool-len+7)/8) octets in length per
I-D.draft-ietf-dhc-option-guidelines. Bits outsides of the pfx-pool-len, if
included, MUST be zero."

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, April 09, 2013 4:35 AM
To: Leaf Yeh; 'Tomek Mrugalski'; 'Ted Lemon'
Cc: [email-masked]
Subject: RE: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

<quote>

The issue here is that if pfx-pool-len is 60, I can provide 0-16 octets of
ipv6-prefix (or depending on how you interpret 8-16 octets).

Probably still not the best. I think we want to have the ipv6-prefix field
to contain only <prefix+7/8> octets. So, for a 60, we would want it to have
8 octets, not more or less?

This is something we should clear up (also in
draft-ietf-dhc-option-guidelines).

The processing might be to initialize 16-octet buffer to all 0's, copy the
ipv6-prefix octets (up to 16) into that buffer. The resulting value is the
prefix.  This would work and even allow the ipv6-prefix to be LESS than the
prefix length when the bits are 0 (such as if 2001::/60 is sent, really only
the first 2 octets are needed).

Or, do we want to be more explicit and say that the size of ipv6-prefix
always should be <prefix length + 7/8> octets.

Note that this makes a big difference when this information is encoded as a
'structured' option (where additional data may follow). It is less of an
issue when this is the only field that is 'variable'. (Note that if we
require the <prefix length +7/8> octets, I would really declare this NOT to
be variable length as there is a length.)

I also fear if we are not clear, we may end up with implementations that
fail to interoperate.

- Bernie

-----Original Message-----
Leaf Yeh

Best Regards,
Leaf

-----Original Message-----

Tomek

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 12 Apr 2013 18:15:26 +0800

Tomek - What I'd like to see is a clarification about status. Something
along the lines "Under normal circumstances the Status field should have
value Active when responding to any client messages, except release and the
status should have value Released only when responding to the Release
message sent by the last active client connected via specific relay. Those
recommendation may not apply if the server configuration has changed".

Clarification - The definition of the 'Statue' of the prefix pool is in
section 4 of this draft.
<quote>
   If the administrative policy on the server permits to support route
   aggregation on the relay agent, the status of prefix pool can be
   determined by the delegated prefixes within the associated prefix
   pool: If there is one delegated prefix within the pool that has a
   valid lease, the status of the prefix pool will be 'Active';
   otherwise, the status of the prefix pool is 'Released'.  If the
   administrative policy on the server does not permit to support route
   aggregation on the relay agent, the status of the prefix pool will
   always be 'Released'.
</quote>
So we can't say 'Under normal circumstances the Status field should have
value Active when responding to any client messages'. I supposed the status
of the prefix pool is 'Released' from the beginning. After there is a client
got a delegated (PD) prefix with a valid lease, then the status of prefix
pool turns to be 'Active', or we can say the prefix pool also got a 'valid'
lease, if the administrator of server configure it to support
OPTION_PREFIX_POOL. If the server is configured to not support
OPTION_PREFIX_POOL, then all the prefix pools are in the status of
'Released', which sounds equal to 'no status', as what we have now on the
server.

Tomek - This also implies that the relays need to to deep packet inspection
and parse IA_PD in relayed responses, but I suppose relays in this
deployment scenario do this anyway, right?

Yes. PE needs to set up the dedicated route entries for each customer
network behind CE per the PD prefixes (and its leases) in IA_PDs.

Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? Your
relay will hijack the whole network? ...

The relay's behavior is still under control by the server. If it got the
wrong configuration, the server could also send out ::/0 in the IA_PD. So
this may sound an administration error. We just want the prefix pools not
configure to be ::/0 or any overlap between them. I feel a little stuck on
the exact text you want. How about 'The administrator of the DHCPv6 server
should pay more attention to the configuration of the prefix pools, for
examples, a. ::/0 may cause a big routing problem in the whole ISP network;
b. the configuration of prefix pool should avoid overlap in the address
plan, and etc.'  ?  I am not quite sure...

Tomek - Bernie had this concern and I tend to agree with him... the length
of ipv6-prefix should be: floor( (prefix-len + 7)/8 )

See my reply to Bernie's email. Thanks for your suggestion here. Do we need
more explanation on the mathematic function of floor() ? :-)

Tomek - ...(I know that requestor in most cases is part of a relay, but from
protocol perspective these are separate entities)...Yes. Please split
actions taken by requestor into separate section. It can be subsection 5.1
if you like to.

Do you mean add section 5.1 "Leasequery Requestor Behavior" in the section 5
"Relay Agent Behavior" (just for an editorial change)? Do you want section
6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"?

Tomek - ...this draft repeats normative language from RFC3315 (e.g. "The
relay agent SHOULD include the Interface ID option")...

After searching and reading, I still can't find this sentence in RFC3315. 

Best Regards,
Leaf

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Tuesday, April 09, 2013 9:20 PM
To: Leaf Yeh
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

On 08.04.2013 19:31, Leaf Yeh wrote:
> Tomek - Issue 1) this draft allows really stupid things, for example: 
> you can release (or stop aggregating) prefix-pool when responding to 
> REQUEST and you can allocate (or rather aggregate) when responding to 
> RELEASE
> 
> Clarification - The key (or permit) of the above mechanism (or 
> behavior) is that OPTION_PREFIX_POOL try to support the 'real-time' 
> setting (or aggregation policy) change by the administrator.
No, the mechanism is more or less ok as it is now. What I'd like to see is a
clarification about status. Something along the lines "Under normal
circumstances the Status field should have value Active when responding to
any client messages, except release and the status should have value
Released only when responding to the Release message sent by the last active
client connected via specific relay. Those recommendation may not apply if
the server configuration has changed".

> Tomek - Issue 2) Take this scenario: the PD for your last client 
> connected through the relay expires (rather than is being released). 
> Your relay will get stuck with outdated info, because there is no 
> other DHCP traffic that server can piggyback on. You could argue that 
> leasequery can help here, but how often would the relay do the query? 
> This may introduce non-trivial amount of extra traffic for the server to
process.
> Or do you want to simplify this mechanism?
I must have missed that part. Ok, that makes sense. This also implies that
the relays need to to deep packet inspection and parse IA_PD in relayed
responses, but I suppose relays in this deployment scenario do this anyway,
right?

> Tomek - There are other smaller issues as well: security 
> considerations is really empty, Any more detailed review comments or 
> suggested text on it?
Come on, there are some easy attack vectors here. What if the server sends
out ::/0 in PREFIX_POOL option? Your relay will hijack the whole network?
This means that if your DHCPv6 server is compromised you can start
controlling (to some degree) traffic in your whole network.

> Tomek - ipv6-prefix field length is not precisely defined, Not quite 
> sure about the issue?
> <quote>
Bernie had this concern and I tend to agree with him. For example you want
to convey 2000:db8::/32 prefix. I can send an option with pfx-pool-len equal
to 32, but the ipv6-prefix containing all 16 bytes.
That option would be still conformant to this draft. The updated
option-guidelines-11 draft says (or rather ought to say, but the text is not
as clear as it should be) that the length of ipv6-prefix should be:

> requestor behavior (I know that requestor in most cases is part of a 
> relay, but from protocol perspective these are separate entities),
> 
Yes. Please split actions taken by requestor into separate section. It can
be subsection 5.1 if you like to.

> Tomek - this draft repeats normative language from RFC3315 (e.g. "The 
> relay agent SHOULD include the Interface ID option"), it is not idnits
clean etc.
> Not quite sure about the issue? Sounds not difficult to fix it?
I didn't say that it is difficult to fix. My understanding is that documents
that reach WGLC phase are expected to be idnits clean, unless there are good
reasons for them to not be. When sending a draft to IESG that do not pass
idnits, it is likely to get an brief response "please fix idnits" and
nothing else. It sometimes takes a lot of time before IESG looks at such a
draft again.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Sun, 14 Apr 2013 05:26:06 -0700

> plan, and etc.'  ?  I am not quite sure...
Administrator mistake is one concern, the other one is that DHCPv6
server may become an attractive attack target when prefix-pool is deployed.

How about "Misconfigured or compromised DHCPv6 server can cause relays
to start announcing arbitrary prefixes, including default routes, which
could lead to traffic hijack."?

> more explanation on the mathematic function of floor() ? :-)
I don't think so. A potential implementor who doesn't know what floor()
function does should probably consider starting a career in some other
industry. :-)

> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"?
Yes to both.

> After searching and reading, I still can't find this sentence in RFC3315.
It is in prefix-pool-opt-02, section 5, second paragraph. Text from
prefix-pool-opt-02 is an imprecise subset of behaviour described in
RFC3315, section 20.1.1, second paragraph. Here's the difference:

RFC3315: relay MUST include interface-id if the link-address in server's
response is not sufficient to select downlink interface.

prefix-pool-opt-02: relay SHOULD include interface-id, so the the server
can identify the relay itself (tomek: that's wrong. Interface-id is for
interface or subnet identification, not relay identification. Relay-id
is used for that purpose, see RFC5460, section 5.4.1) if the server
would not like to use the link-address field specified in RELAY-FORW
message (tomek: that imprecise or wrong. The server is not at liberty to
"not use link-address field". There's a specific algorithm defined in
section 11 of RFC3315 that the server must follow it).

Tomek

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 17 Apr 2013 19:07:00 +0800

Tomek - How about "Misconfigured or compromised DHCPv6 server can cause
relays to start announcing arbitrary prefixes, including default routes,
which could lead to traffic hijack."?

I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't bought in
the part of 'Compromised DHCPv6 server'. I don't believe the ORO option
included by the relay could compromise the DHCPv6 server. Right?

> Tomek - ...this draft repeats normative language from RFC3315 (e.g. 
> "The relay agent SHOULD include the Interface ID option")...

Section 6 of the draft (OPTION_PREFIX_POOL) has the following text:
  "The server MAY use the link-address specified in RELAY-FORW message
   to identify the relay agent itself or its particular customer-facing
   interface where the prefix pool is associated, but the server has to
   maintain the binding data of prefix pools in association with these
   link-addresses.  To be more readable, the server can alternatively
   use the Interface ID option included in the RELAY-FORW message by the
   relay agent to identify the relay agent itself or its particular
   customer-facing interface where the prefix pool is associated.  In
   order to give a meaningful reply, the server has to maintain the
   binding data of prefix pools in association with the information
   derived from the Interface ID option."
The draft (OPTION_PREFIX_POOL) recommends to use interface-id for both use
cases shown in section 3.

Tomek -RFC3315: relay MUST include interface-id if the link-address in
server's response is not sufficient to select downlink interface.
prefix-pool-opt-02: relay SHOULD include interface-id, so the the server can
identify the relay itself 
(tomek: that's wrong. Interface-id is for interface or subnet
identification, not relay identification. Relay-id is used for that purpose,
see RFC5460, section 5.4.1)

There might be a small debate here. The question could be whether the server
could identify the relay after receiving the interface-id of it. I guess our
smart server already support that in the real deployment. [Pls. refer to
'Access Node identifier' in BBF TR-177
(http://www.broadband-forum.org/technical/trlist.php ) and its R-30: The
BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be able to
use Option 18 in order to retrieve the Access Node identifier and access
this table in order to identify the ad-hoc pool of prefixes or addresses.]

OTOH, I believe relay-id defined in RFC5460 can also be used in the case 1
(or Fig. 1) of section 3, but can't be used for case 2 (or Fig. 2); though
if the mechanism of Bulk-Lease-Query is employed, the relay also need to
include OPTION_ RELAY_ID in the relay-forward message for the basic
operation of DHCPv6 prefix or address assignment. 

Tomek - ... if the server would not like to use the link-address field
specified in RELAY-FORW message 
(tomek: that imprecise or wrong. The server is not at liberty to "not use
link-address field". There's a specific algorithm defined in section 11 of
RFC3315 that the server must follow it).

Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, has the
following text: 
  " A server selects addresses to be assigned to an IA according to the
   address assignment policies determined by the server administrator
   and the specific information the server determines about the client
   from some combination of the following sources:
   -  The link to which the client is attached. ... If the server receives
the message from a forwarding relay 
         agent, then the client is on the same link as the one to which
         the interface, identified by the link-address field in the
         message from the relay agent, is attached...
   -  The DUID supplied by the client.
   -  Other information in options supplied by the client.
   -  Other information in options supplied by the relay agent."
The above text sounds not put link-address ahead of options supplied by the
relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF TR-177, its R-07,
R-08 & section6.6 (...In some deployments there is neither a need nor a
desire to configure a global or unique local address to the interface on
which the client messages are received. Such a deployment does not allow the
BNG to insert an IPv6 address in the link-address field...).]

Best Regards,
Leaf

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Sunday, April 14, 2013 8:26 PM
To: Leaf Yeh
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

On 13-04-12 03:15, Leaf Yeh wrote:
> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? 
> Your relay will hijack the whole network? ...
> 
> The relay's behavior is still under control by the server. If it got 
> the wrong configuration, the server could also send out ::/0 in the 
> IA_PD. So this may sound an administration error. We just want the 
> prefix pools not configure to be ::/0 or any overlap between them. I 
> feel a little stuck on the exact text you want. How about 'The 
> administrator of the DHCPv6 server should pay more attention to the 
> configuration of the prefix pools, for examples, a. ::/0 may cause a 
> big routing problem in the whole ISP network; b. the configuration of 
> prefix pool should avoid overlap in the address plan, and etc.'  ?  I am
not quite sure...
Administrator mistake is one concern, the other one is that DHCPv6 server
may become an attractive attack target when prefix-pool is deployed.

How about "Misconfigured or compromised DHCPv6 server can cause relays to
start announcing arbitrary prefixes, including default routes, which could
lead to traffic hijack."?

> Tomek - Bernie had this concern and I tend to agree with him... the 
> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my 
> reply to Bernie's email. Thanks for your suggestion here. Do we need 

> Tomek - ...(I know that requestor in most cases is part of a relay, 
> but from protocol perspective these are separate entities)...Yes. 
> Please split actions taken by requestor into separate section. It can 
> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the 
> section 5 "Relay Agent Behavior" (just for an editorial change)? Do 
> you want section
Yes to both.

> Tomek - ...this draft repeats normative language from RFC3315 (e.g. 
> "The relay agent SHOULD include the Interface ID option")...
> 
It is in prefix-pool-opt-02, section 5, second paragraph. Text from
prefix-pool-opt-02 is an imprecise subset of behaviour described in RFC3315,
section 20.1.1, second paragraph. Here's the difference:

prefix-pool-opt-02: relay SHOULD include interface-id, so the the server can
identify the relay itself (tomek: that's wrong. Interface-id is for
interface or subnet identification, not relay identification. Relay-id is
used for that purpose, see RFC5460, section 5.4.1) if the server would not
like to use the link-address field specified in RELAY-FORW message (tomek:
that imprecise or wrong. The server is not at liberty to "not use
link-address field". There's a specific algorithm defined in section 11 of
RFC3315 that the server must follow it).

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 17 Apr 2013 11:48:33 +0000

Fyi - 
> To be more readable, the server can alternatively
>   relay agent to identify the relay agent itself 

The interface id option can not be used to identify the relay. There is no requirement that the interface id is globally unique - it only has significance to the relay itself.

- Bernie

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 19 Apr 2013 11:20:38 +0800

BV> The interface id option can not be used to identify the relay. There is
no requirement that the interface id is globally unique - it only has
significance to the relay itself.

If we decide to come back & comply with the exact language of IETF defined
before, how about to update the text in section 5 to be 

"The relay agent SHOULD include the Relay ID option (OPTION_RELAY_ID, 53) or
Interface ID option (OPTION_INTERFACE_ID, 18) so that the server can
identify the relay agent itself or its particular customer-facing interface
with which the prefix pool is associated, if the server can not use the
link-address field specified in the encapsulation of the DHCPv6 RELAY-FORW
message to identify the interface of the link on which the clients are
located."

and the text in section 6 to be

"The server MAY use the link-address specified in RELAY-FORW message to
identify the relay agent itself and its particular customer-facing interface
where the prefix pool is associated, but the server has to maintain the
binding data of prefix pools in association with these link-addresses. To be
more readable, the server can alternatively use Relay-ID and Interface-ID
option included in the RELAY-FORW message by the relay agent to identify the
relay agent itself and its particular customer-facing interface where the
prefix pool is associated. In order to give a meaningful reply, the server
has to maintain the binding data of prefix pools in association with these
Relay-ID and Interface-ID. According to DHCPv6 [RFC3315], the server SHOULD
copy the Interface-ID option from the RELAY-FORW message into the RELAY-REPL
message."

Does the server need to copy Relay-ID from the RELAY-FORW into the
RELAY-REPL?

Best Regards,
Leaf

PS. Note that the Fig.1 & 2 in section 3 will be updated accordingly.

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Wednesday, April 17, 2013 7:49 PM
To: Leaf Yeh
Cc: Tomek Mrugalski; [email-masked]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

Fyi - 
>   relay agent to identify the relay agent itself

The interface id option can not be used to identify the relay. There is no
requirement that the interface id is globally unique - it only has
significance to the relay itself.

- Bernie

On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" <[email-masked]> wrote:

> Tomek - How about "Misconfigured or compromised DHCPv6 server can 
> cause relays to start announcing arbitrary prefixes, including default 
> routes, which could lead to traffic hijack."?
> 
> I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't 
> bought in the part of 'Compromised DHCPv6 server'. I don't believe the 
> ORO option included by the relay could compromise the DHCPv6 server.
Right?
> The draft (OPTION_PREFIX_POOL) recommends to use interface-id for both 
> use cases shown in section 3.
> 
> 
> prefix-pool-opt-02: relay SHOULD include interface-id, so the the 
> server can identify the relay itself
> identification, not relay identification. Relay-id is used for that 
> purpose, see RFC5460, section 5.4.1)
> 
> There might be a small debate here. The question could be whether the 
> server could identify the relay after receiving the interface-id of 
> it. I guess our smart server already support that in the real 
> deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177 
> (http://www.broadband-forum.org/technical/trlist.php ) and its R-30: 
> The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be 
> able to use Option 18 in order to retrieve the Access Node identifier 
> and access this table in order to identify the ad-hoc pool of prefixes 
> or addresses.]
> 
> OTOH, I believe relay-id defined in RFC5460 can also be used in the 
> case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig. 
> 2); though if the mechanism of Bulk-Lease-Query is employed, the relay 
> also need to include OPTION_ RELAY_ID in the relay-forward message for 
> the basic operation of DHCPv6 prefix or address assignment.
> 
> 
> (tomek: that imprecise or wrong. The server is not at liberty to "not 
> use link-address field". There's a specific algorithm defined in 
> section 11 of
> Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, 
> has the following text:
>   -  The link to which the client is attached. ... If the server 
> receives the message from a forwarding relay
> The above text sounds not put link-address ahead of options supplied 
> by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF 
> TR-177, its R-07,
> R-08 & section6.6 (...In some deployments there is neither a need nor 
> a desire to configure a global or unique local address to the 
> interface on which the client messages are received. Such a deployment 
> does not allow the BNG to insert an IPv6 address in the link-address 
> field...).]
> 
> 
> Best Regards,
> Leaf
> 
> 
> 
> to start announcing arbitrary prefixes, including default routes, 
> I don't think so. A potential implementor who doesn't know what 
> floor() function does should probably consider starting a career in 
> some other industry. :-)
> 
> RFC3315: relay MUST include interface-id if the link-address in 
> prefix-pool-opt-02: relay SHOULD include interface-id, so the the 
> server can identify the relay itself (tomek: that's wrong. 
> Interface-id is for interface or subnet identification, not relay 
> identification. Relay-id is used for that purpose, see RFC5460, 
> section 5.4.1) if the server would not like to use the link-address field

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 19 Apr 2013 03:27:22 +0000

OK, that wasn't a requirement in RFC 3315 so if this draft assumes that it is (based on other standards), that needs to be clarified in the document - that it requires the Interface-ID is sufficiently unique (as per [references]).

-          Bernie

From: Leaf Yeh [mailto:[email-masked]]
Sent: Thursday, April 18, 2013 11:22 PM
To: Bernie Volz (volz)
Cc: 'Tomek Mrugalski'; 'Ted Lemon'
Subject: RE: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013

BV> The interface id option can not be used to identify the relay. There is no requirement that the interface id is globally unique - it only has significance to the relay itself.

The documents of BBF TR-177 & TR-101 has different idea & requirements on the usage of Interface-ID.

TR-177 R-07

"The Access Node MUST, when performing the function of an LDRA, be able to

encode the access loop identification in the Interface-Id Option (option 18, defined in

RFC 3315 [14]) and add the option to the DHCPv6 Relay-forward messages sent to

the BNG, which acts as a DHCPv6 server or a DHCPv6 Relay Agent."

Note: LDRA is the RA defined in RFC6221.

TR-177 R-08

"When adding the Interface-Id, the encoding MUST uniquely identify the Access

Node and the access loop logical port on the Access Node on which the DHCPv6

message was received. The Interface-Id contains a locally administered ASCII string

generated by the Access Node, representing the corresponding access loop logical

port (U interface). The actual syntax of the access loop identification in the Interface-

Id is identical to the syntax defined in Section 3.9.3/TR-101 and Section 5.7/TR-156."

TR-177 R-30

"The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be able to

use Option 18 in order to retrieve the Access Node identifier and access this table in

order to identify the ad-hoc pool of prefixes or addresses."

& text in section 6.6 of TR-177

"In some deployments there is neither a need nor a desire to configure a global or unique local

address to the interface on which the client messages are received. Such a deployment does not

allow the BNG to insert an IPv6 address in the link-address field. Having the BNG insert an

Interface-Id option (Optoin 18) allows identification of the interface on which the client

messages are received, ...

As introduced in this section, it can be deduced that the best solution for a DHCPv6 Delegating

Router or Server to identify the pool of prefixes to be used for assignment consists of relying on

the Interface-Id option (Optoin 18) inserted by the Access Node and more precisely on the

Access Node identifier contained in this option.

The operator must maintain a table binding the Access Node identifier with the corresponding

pool of prefixes. The DHCPv6 Delegating Router or DHCPv6 Server must be able to use Option

18 in order to retrieve the Access Node identifier and access this table in order to identify the adhoc

pool of prefixes or addresses (see R-30).

The main advantage of this solution is that it does not bring any requirement to access or

backhaul devices; additional functionality is only required on the DHCPv6 delegating router or

server..."

Note: Wojciech (Dec of Cisco) is the one of the editor of BBF-177

All of the above are still not the language of IETF, but the requirements from the industry.

The above text means the interface-id could be unique local in the administrator domain.

Could the same logic be applied in the use cases of draft (OPTION_PREFIX_POOL), or we just to speak the pure IETF RFC's language?

Best Regards,

Leaf

PS.

Section 3.9.3 @ TR-101

Section 5.7 @ TR-156

-----Original Message-----

To: Leaf Yeh

Cc: Tomek Mrugalski; [email-masked]<mailto:[email-masked]>

Fyi -

- Bernie

> ORO option included by the relay could compromise the DHCPv6 server. Right?

> section 11 of

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

>> prefix pool should avoid overlap in the address plan, and etc.'  ?  I

>> am

> section 5.4.1) if the server would not like to use the link-address field specified in RELAY-FORW message (tomek:

> link-address field". There's a specific algorithm defined in section

> 11 of

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Apr 2013 05:57:56 +0000

On Apr 18, 2013, at 11:27 PM, "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>> wrote:
OK, that wasn’t a requirement in RFC 3315 so if this draft assumes that it is (based on other standards), that needs to be clarified in the document – that it requires the Interface-ID is sufficiently unique (as per [references]).

I'm skeptical that there is any presumption of uniqueness to the interface ID alone; combined with the IP address of the relay agent, you have a unique identifier.   Leaf, do you have any direct experience with this sort of configuration?

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 19 Apr 2013 16:43:47 +0800

Ted - .the interface ID.combined with the IP address of the relay agent, you
have a unique identifier.

That is a good idea, we do have the Global Unicast Address (GUA) on the
relay (or its network-facing interface) for the communication between the
relay and the server. It sound much better than DUID, which sounds
associated with the hardware to get the global uniqueness. 

Ted - . do you have any direct experience with this sort of configuration?

The Broadband Forum Technical Reports (TR-101/156/177-IPv6) are mostly  for
the spec. (or requirements) of access network equipments. They do have
Access Node Identifier included in the Interface-ID (Table 2 in TR-101
titled Circuit ID Syntax & Table 1 in TR-156 titled Port Identification
String Elements) for Layer 2 DHCP relay agent (or PPPoE Intermediate Agent)
on the Access Node. That makes the interface-id be unique-local in the
administrator domain, which sounds a Must when a PE router connect multiple
Access Nodes through Ethernet. In their use cases, the access nodes (or even
LDRAs) don't always have the IPv6-GUAs in their control (or protocol)-plane.

The previous versions of my draft try to apply the same idea as that of
TR-177,  but it employ the administrative unique interface-id for layer-3
device, a PE router. So we don't have any direct experience with this sort
of configuration yet. But in theory there sounds no difference whether the
relay is layer-2 or layer-3, when the relay include interface-id. 

The administrative unique interface-id might be more readable than IPv6-GUA
when configuring the binding relationship with prefix pools on the server,
but sounds a little more administrative. 

Thanks to Tomek for his catch to this further discussion.

Best Regards,

Leaf

From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, April 19, 2013 1:58 PM
To: Bernie Volz (volz)
Cc: Leaf Yeh; Tomek Mrugalski; [email-masked]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

On Apr 18, 2013, at 11:27 PM, "Bernie Volz (volz)" <[email-masked]> wrote:

OK, that wasn't a requirement in RFC 3315 so if this draft assumes that it
is (based on other standards), that needs to be clarified in the document -
that it requires the Interface-ID is sufficiently unique (as per
[references]).

I'm skeptical that there is any presumption of uniqueness to the interface
ID alone; combined with the IP address of the relay agent, you have a unique
identifier.   Leaf, do you have any direct experience with this sort of
configuration?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 19 Apr 2013 12:15:55 +0000

Yes, using relay-id should solve the problem of uniquess. Lacking that, perhaps GUA can be used but is not as good. 

Server does not echo back relay-id unless Relay asked it to using the ERO.

- Bernie

---

From: "Leaf Yeh" <[email-masked]>
Date: Sat, 20 Apr 2013 18:20:57 +0800

The OPTION_RELAY_ID defined in RFC 5460 employs the DUID, which is
associated with the hardware (or link-layer) address, time of generation or
assigned to the DU at the time of manufacture, and has 3 formats (type
1-LTT, 2-EN, 3-LL) defined in RFC3315. These DUIDs sounds not easy to
collect beforehand & unfriendly to read by the administrator, who need that
to configure the binding relation with the prefix pools on the server for
the right prefix delegation (or assignment).

Let's go back to the basic relay case of DHCPv6-PD without the mechanism
introduced in this draft (OPTION_PREFIX_POOL), how to assign a prefix from a
particular pool to the CE? I suppose the basic relay case has the same
problem of the uniqueness. GUA(+interface-id) of relay sounds much easy &
readable than DUID(+interface-id). 

Otherwise, could we update the format of OPTION_RELAY_ID defined in RFC5460
to be:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_RELAY_ID         |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            relay-ID                           .
.                        (variable length)                      .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code   OPTION_RELAY_ID.
option-len    Length of DUID in octets.
relay-ID      An opaque value of arbitrary length configured
              by the relay agent.

which sounds the same requirement on the administrative uniqueness as that
of interface-id, but keep the interface-id to only have significance to the
relay itself. 

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Friday, April 19, 2013 8:16 PM
To: Leaf Yeh
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

Yes, using relay-id should solve the problem of uniquess. Lacking that,
perhaps GUA can be used but is not as good. 

- Bernie

On Apr 18, 2013, at 11:20 PM, "Leaf Yeh" <[email-masked]> wrote:

> BV> The interface id option can not be used to identify the relay. 
> BV> There is
> If we decide to come back & comply with the exact language of IETF 
> defined before, how about to update the text in section 5 to be
> 
> "The relay agent SHOULD include the Relay ID option (OPTION_RELAY_ID, 
> 53) or Interface ID option (OPTION_INTERFACE_ID, 18) so that the 
> server can identify the relay agent itself or its particular 
> customer-facing interface with which the prefix pool is associated, if 
> the server can not use the link-address field specified in the 
> encapsulation of the DHCPv6 RELAY-FORW message to identify the 
> interface of the link on which the clients are located."
> 
> to identify the relay agent itself and its particular customer-facing 
> link-addresses. To be more readable, the server can alternatively use 
> Relay-ID and Interface-ID option included in the RELAY-FORW message by 
> the relay agent to identify the relay agent itself and its particular 
> binding data of prefix pools in association with these Relay-ID and 
> Interface-ID. According to DHCPv6 [RFC3315], the server SHOULD copy 
> the Interface-ID option from the RELAY-FORW message into the RELAY-REPL
message."
>> To be more readable, the server can alternatively  use the Interface 
>> ID option included in the RELAY-FORW message by the  relay agent to 
>> identify the relay agent itself
> 
> The interface id option can not be used to identify the relay. There 
> is no requirement that the interface id is globally unique - it only 
> has significance to the relay itself.
> 
> - Bernie
> 
>> cause relays to start announcing arbitrary prefixes, including 
>> default routes, which could lead to traffic hijack."?
>> 
>> bought in the part of 'Compromised DHCPv6 server'. I don't believe 
>> the ORO option included by the relay could compromise the DHCPv6 server.
> Right?
>> 
>> 
>> The draft (OPTION_PREFIX_POOL) recommends to use interface-id for 
>> both use cases shown in section 3.
>> 
>> 
>> Tomek -RFC3315: relay MUST include interface-id if the link-address 
>> in server's response is not sufficient to select downlink interface.
>> and access this table in order to identify the ad-hoc pool of 
>> prefixes or addresses.]
>> 
>> 2); though if the mechanism of Bulk-Lease-Query is employed, the 
>> relay also need to include OPTION_ RELAY_ID in the relay-forward 
>> message for the basic operation of DHCPv6 prefix or address assignment.
>> 
>> 
>> Tomek - ... if the server would not like to use the link-address 
>> field specified in RELAY-FORW message
>> interface on which the client messages are received. Such a 
>> deployment does not allow the BNG to insert an IPv6 address in the 
>> link-address field...).]
>> 
>> 
>> Best Regards,
>> Leaf
>> 
>> 
>> 
>>> big routing problem in the whole ISP network; b. the configuration 
>>> of prefix pool should avoid overlap in the address plan, and etc.'  
>>> ?  I am
>> not quite sure...
>> How about "Misconfigured or compromised DHCPv6 server can cause 
>> relays to start announcing arbitrary prefixes, including default 
>>> Please split actions taken by requestor into separate section. It

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 20 Apr 2013 15:15:19 +0000

(WG co-chair hat off.)

There are multiple forms of DUID - two of which are not associated with link-layer addresses (DUID-EN and DUID-UUID). Cable Modems have been using the DUID-LL because that makes it easy as the mac-address has been used for V4 and it is easy enough to map this to the DUID-LL.

For RFC 5460, using the DUID seemed like a good approach - DHCPv6 was using DUID for clients and servers already, so why not relays. The recent proposal for DHCPv4 Relay ID (almost out as an RFC) is not as strict as RFC 5460.

I don't think we want to "replace" the existing v6 Relay-ID option with alternatives, but that it something that is always up to the WG. I think this would mean defining a new option as it would be bad to reuse this existing option for something that is clearly not a DUID (perhaps you can get a new DUID type defined that allows for an 'opaque' identifier - but I suspect that won't be easy as this would lead to the same issues as exist with the DHCPv4 "client-id" where two people can use the same identifier).

Again, if the Interface-ID is unique enough by other standards which would have to apply when prefix-pool is used, then there is no issue - but this would have to be a clear requirement of using prefix-pool. Personally, I think this will be missed and is not a good idea.

Whatever identifier is used is always problematic as replacing the hardware will likely require configuring the old identifier into that new hardware or updating the server's database. Using an address causes similar issues if renumbering were to occur. Also, an address may cause problems when there are multiple relays being used (yes, it is in the peer-address field) but depending on the 'next hop' destination address used by the relay, it may not be a GUA (the stack may pick a different source address).

The Interface-ID (if containing enough to make it 'unique' across devices, not just within a device) has these same issues - replacing the relay or renumbering may change the 'interface-id'.

I think you should just use the tools presently available (i.e., Relay ID & Interface ID options) as alternatives are unlikely to have sufficient benefits.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Saturday, April 20, 2013 6:21 AM
To: Bernie Volz (volz); 'Tomek Mrugalski'
Cc: [email-masked]; 'Ted Lemon'
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02

The OPTION_RELAY_ID defined in RFC 5460 employs the DUID, which is associated with the hardware (or link-layer) address, time of generation or assigned to the DU at the time of manufacture, and has 3 formats (type 1-LTT, 2-EN, 3-LL) defined in RFC3315. These DUIDs sounds not easy to collect beforehand & unfriendly to read by the administrator, who need that to configure the binding relation with the prefix pools on the server for the right prefix delegation (or assignment).

Let's go back to the basic relay case of DHCPv6-PD without the mechanism introduced in this draft (OPTION_PREFIX_POOL), how to assign a prefix from a particular pool to the CE? I suppose the basic relay case has the same problem of the uniqueness. GUA(+interface-id) of relay sounds much easy & readable than DUID(+interface-id). 

Otherwise, could we update the format of OPTION_RELAY_ID defined in RFC5460 to be:

 0                   1                   2                   3

which sounds the same requirement on the administrative uniqueness as that of interface-id, but keep the interface-id to only have significance to the relay itself. 

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, April 19, 2013 8:16 PM
To: Leaf Yeh
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013

- Bernie

message."

---

From: "Leaf Yeh" <[email-masked]>
Date: Sun, 21 Apr 2013 23:13:55 +0800

BV>For RFC 5460, using the DUID seemed like a good approach - DHCPv6 was
using DUID for clients and servers already, so why not relays. The recent
proposal for DHCPv4 Relay ID (almost out as an RFC) is not as strict as RFC
5460.

Solution A - RFC 5460 may have no problem when relay-id uses DUID, because
the server seems only record the relay-id in the process of prefix
delegation, not use the relay-id for the client's prefix selecting &
assignment.

RFC5460 
<quote>
   This specification includes a new DHCPv6 option, the Relay-ID option.
   The option contains a DUID (DHCP Unique Identifier) identifying a
   DHCPv6 relay agent.  Relay agents can include this option in Relay-
   Forward messages they send.  Servers can retain the Relay-ID and
   associate it with bindings made on behalf of the relay's clients.  A
   relay can then recover binding information about downstream clients
   by using the Relay-ID in a LEASEQUERY message.
</quote>

BV>Whatever identifier is used is always problematic as replacing the
hardware will likely require configuring the old identifier into that new
hardware or updating the server's database. 

Solution B - If GUA of the relay is used for the ID, then configure it into
that new hardware, but no need to update this part of the server's database.
I meant the IPv6 address plan has no change; the ID of the relay here need
be configurable & readable.

BV>Using an address causes similar issues if renumbering were to occur. 

If IPv6 address renumbering of the relay occurs, that sounds the address
plan has changed. We need re-configure the binding relationship (GUA of the
relay -> prefix Pool) in the server's database.

BV>Also, an address may cause problems when there are multiple relays being
used (yes, it is in the peer-address field) but depending on the 'next hop'
destination address used by the relay, it may not be a GUA (the stack may
pick a different source address).

I wonder what kind of the ID for relay is used for the basic (or general)
case of DHCPv6-PD. GUA sounds a good choice for ID there, but the DUID might
not be so popular there. At least RFC3633 has not mentioned it.

BV>The Interface-ID (if containing enough to make it 'unique' across
devices, not just within a device) has these same issues - replacing the
relay or renumbering may change the 'interface-id'.

Solution C - If 'syntax' of the interface-id is independent with the
hardware of the relay, replacing the relay or (IPv6 address) renumbering the
relay may not change the interface-id. If the new & the old relay is the
same type, there could be no change in the interface-id; for example,
interface-id is only related with the location of the interface.

But if you really concern solution C (not a tool presently available ), I
would prefer solution B.

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Saturday, April 20, 2013 11:15 PM
To: Leaf Yeh; 'Tomek Mrugalski'
Cc: [email-masked]; 'Ted Lemon'
Subject: RE: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02

(WG co-chair hat off.)

There are multiple forms of DUID - two of which are not associated with
link-layer addresses (DUID-EN and DUID-UUID). Cable Modems have been using
the DUID-LL because that makes it easy as the mac-address has been used for
V4 and it is easy enough to map this to the DUID-LL.

For RFC 5460, using the DUID seemed like a good approach - DHCPv6 was using
DUID for clients and servers already, so why not relays. The recent proposal
for DHCPv4 Relay ID (almost out as an RFC) is not as strict as RFC 5460.

I don't think we want to "replace" the existing v6 Relay-ID option with
alternatives, but that it something that is always up to the WG. I think
this would mean defining a new option as it would be bad to reuse this
existing option for something that is clearly not a DUID (perhaps you can
get a new DUID type defined that allows for an 'opaque' identifier - but I
suspect that won't be easy as this would lead to the same issues as exist
with the DHCPv4 "client-id" where two people can use the same identifier).

Again, if the Interface-ID is unique enough by other standards which would
have to apply when prefix-pool is used, then there is no issue - but this
would have to be a clear requirement of using prefix-pool. Personally, I
think this will be missed and is not a good idea.

Whatever identifier is used is always problematic as replacing the hardware
will likely require configuring the old identifier into that new hardware or
updating the server's database. Using an address causes similar issues if
renumbering were to occur. Also, an address may cause problems when there
are multiple relays being used (yes, it is in the peer-address field) but
depending on the 'next hop' destination address used by the relay, it may
not be a GUA (the stack may pick a different source address).

The Interface-ID (if containing enough to make it 'unique' across devices,
not just within a device) has these same issues - replacing the relay or
renumbering may change the 'interface-id'.

I think you should just use the tools presently available (i.e., Relay ID &
Interface ID options) as alternatives are unlikely to have sufficient
benefits.

- Bernie

-----Original Message-----

 0                   1                   2                   3

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, April 19, 2013 8:16 PM
To: Leaf Yeh
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -
Respond by April 8, 2013

- Bernie

message."
>> - Respond by April 8, 2013
>>