Subject: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 8 Jul 2016 19:03:10 +0200

Hi all,

So the day finally has come. Authors working on RFC3315bis believe that
after over two years of work, this document is ready for working group
last call. This call initiates the working group last call on
draft-ietf-dhc-rfc3315bis-05 [1]. Since this is a large document (130+
pages), there's upcoming meeting and a holiday period, chairs decided to
do an extended last call that will last 4 weeks. Please post your
comments by August 8th.

We do have a slot reserved for this work in Berlin. We will present the
overview of the document (some areas are organized differently than
original 3315), go over the most important changes and will discuss any
comments raised to date.

If you would like to review more important changes, looking at
appendices A anb B seems like a good place to start. If you like to see
the list of tickets addressed, see [2]. Many smaller issues were
discussed on dhcpv6bis mailing list [3].

This is the most important document the DHC working group is currently
working on. Please review it thoroughly. Since both co-chairs are also
co-authors, our shepherd, Ralph Droms, will determine consensus and wrap
up the WGLC. Thank you Ralph for stepping up and helping with this!

1. https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-05
2. https://tools.ietf.org/group/dhcpv6bis/
3. https://www.ietf.org/mailman/listinfo/dhcpv6bis

Cheers,
Bernie & Tomek

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Jul 2016 08:33:44 +0200

On Fri, Jul 8, 2016 at 7:03 PM, Tomek Mrugalski <[email-masked]>
wrote:

> This call initiates the working group last call
> on draft-ietf-dhc-rfc3315bis-05 [1].

rfc3315bis is written to assume that a client requesting a prefix via
DHCPv6 prefix delegation is a router. The term "requesting router" is used
throughout. But it is useful to delegate prefixes to hosts, as well.

For example, draft-templin-aerolink and draft-herbert-nvo3-ila and
draft-ietf-v6ops-unique-ipv6-prefix-per-host all mention assigning a /64
prefix to a host. But because RFC3315 still talks about "requesting
router", when we wrote draft-ietf-v6ops-host-addr-availability (now in
AUTH48) we had to say:

      While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6
      PD itself does not require that the client forward IPv6 packets
      not addressed to itself, and thus does not require that the client
      be an IPv6 router as defined in [RFC2460].  Also, in many cases
      (such as tethering, or hosting virtual machines), hosts are
      already forwarding IPv6 packets and thus operating as IPv6 routers
      as defined in [RFC2460].

In 3315bis, can we use another term instead of "requesting router"?
"Client"? "Requesting node"?

Cheers,
Lorenzo

---

From: Marcin Siodelski <[email-masked]>
Date: Wed, 20 Jul 2016 08:46:55 +0200

On 20.07.2016 08:33, Lorenzo Colitti wrote:
> On Fri, Jul 8, 2016 at 7:03 PM, Tomek Mrugalski
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> DHCPv6 prefix delegation is a router. The term "requesting router" is
> used throughout. But it is useful to delegate prefixes to hosts, as well.
>

After merging RFC3633 into the RFC3315, many of the sections (in
particular those talking about the messages transmission and reception)
include common text for processing IA_NAs and IA_PDs and they use the
term "Client" (as it used to be in original RFC3315) for an entity that
can request addresses and prefixes. Hence, I'd suggest we continue using
the term "Client" where possible, which probably also means replacing
some of 72 occurrences of "delegating router". Perhaps we should also
update section "5.3.  DHCP for Prefix Delegation" to say that prefix
delegation is a mechanism that can be used to provide prefixes to
routers but also hosts.

Marcin

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Jul 2016 09:26:54 +0200

On Wed, Jul 20, 2016 at 8:46 AM, Marcin Siodelski <[email-masked]>
wrote:
>
> which probably also means replacing some of 72 occurrences of "delegating
> router".

+1. I would expect that in most real-world cases "delegating router" isn't
correct anyway, because the prefix is delegated by the server and is
injected into the routing system via relay snooping.

Perhaps we should also update section "5.3.  DHCP for Prefix Delegation" to
> say that prefix delegation is a mechanism that can be used to provide
> prefixes to routers but also hosts.
>

+1.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jul 2016 11:13:53 +0200

Hello,

I would like to ask you whether the YANG model in 
draft-ietf-dhc-dhcpv6-yang-03 has been developped starting from some 
existing MIB?   Which one?  Or maybe it has been developped from scratch?

Also, I would like to tell that in some SDN implementation I am involved 
with, the YANG models are considered compared to the use of JSON.  At 
this time we still debate which one we should use.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jul 2016 17:00:36 +0200

Hello,

There was a discussion today in the DHC WG meeting about the DHCPv6bis 
XML.  One issue raised was that maybe a clarification was needed about 
the problem of a Relay in a DHCPv6 Prefix Delegation setting.

We wrote a draft earlier on a problem in this setting:
draft-petrescu-relay-route-pd-problem-00

Alex

---

From: <[email-masked]>
Date: Thu, 21 Jul 2016 12:17:36 +0000

Hi,

I think this was answered in the room, but it bears saying again here.

The model was not designed following any specific client/server/relay implementation, but as the authors are familiar with a few different variants of these, their configuration will probably have influenced the design. The intention is certainly to keep it agnostic, though.

We are currently looking at modelling the configuration of some specific implementations so that we can compare them to the model in the draft.

Cheers,
Ian

On 20/07/16 11:13, "dhcwg on behalf of Alexandre Petrescu" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,

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

---

From: Ian Farrer <[email-masked]>
Date: Mon, 25 Jul 2016 17:08:15 +0200

Hi Alexandru,

Thanks for the pointer to the document. I’ve had a look through it and whilst it’s certainly related, the specific problem that I’m seeing in vendor’s implementations is only really touched upon in Section 5.1. Yes, snooping is implemented, but the way that this is implemented, the messages that do/don’t get forwarded and the errors that get generated when things are not working are pretty much variable from vendor to vendor (and in one case, there are two different implementations in the same platform with differing behaviours).

I would like to see an effort to define this behaviour better and volunteer to work on it. I’m not sure whether this draft is necessarily the right starting point as it’s more concerned with the route advertisement part of the problem and enumerating ways that this could be performed, but it really depends on how this problem is scoped.

I’m also aware that RFC7513 section 6 has quite some detail of how DHCPv6 snooping works in SAVI for DHCP. I haven’t been through this in detail yet, but it’s probably got useful stuff in there.

Cheers,
Ian

> On 20 Jul 2016, at 17:00, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hello,
> 
> There was a discussion today in the DHC WG meeting about the DHCPv6bis XML.  One issue raised was that maybe a clarification was needed about the problem of a Relay in a DHCPv6 Prefix Delegation setting.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 26 Jul 2016 15:54:37 +0200

Hi Ian,

Le 25/07/2016 à 17:08, Ian Farrer a écrit :
> Hi Alexandru,
>
> Thanks for the pointer to the document. I’ve had a look through it
> and whilst it’s certainly related, the specific problem that I’m
> seeing in vendor’s implementations is only really touched upon in
> Section 5.1. Yes, snooping is implemented, but the way that this is
> implemented, the messages that do/don’t get forwarded and the errors
>  that get generated when things are not working are pretty much
> variable from vendor to vendor (and in one case, there are two
> different implementations in the same platform with differing
> behaviours).
>
> I would like to see an effort to define this behaviour better and
> volunteer to work on it. I’m not sure whether this draft is
> necessarily the right starting point as it’s more concerned with the
>  route advertisement part of the problem and enumerating ways that
> this could be performed, but it really depends on how this problem is
> scoped.

Our concern is mostly related to routing (may need routing table
insertion/deletion upon prefix allocation, depending on the addressing
architecture).

At the same time I agree other aspects than just routing need to be
considered at Relay during the Prefix Delegation operation.

In that sense I am interested if new draft gets started.

> I’m also aware that RFC7513 section 6 has quite some detail of how
> DHCPv6 snooping works in SAVI for DHCP. I haven’t been through this
> in detail yet, but it’s probably got useful stuff in there.

Would need to check how SAVI relates to the dynamically allocated prefix.

Further, I wonder (1) what the security considerations section would
contain and (2) which platform vendor has equipment supporting Prefix
Delegation.

Alex

> Cheers, Ian
>> There was a discussion today in the DHC WG meeting about the
>> DHCPv6bis XML.  One issue raised was that maybe a clarification was
>> needed about the problem of a Relay in a DHCPv6 Prefix Delegation
>> setting.
>>
>> _______________________________________________ dhcwg mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Jul 2016 21:08:25 +0000

BTW: There may also be something in the CableLabs DOCSIS specifications, but I'm not sure it was detailed.

Also, depending on what happens with seDHCPv6, we may need to dust of earlier work, such as https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate, as snooping would be difficult for the relay(s) when the client/server interactions is encrypted.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Tuesday, July 26, 2016 9:55 AM
To: Ian Farrer <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] DHCP Relay and Prefix Delegation

Hi Ian,

Alex

---

From: 神明達哉 <[email-masked]>
Date: Thu, 28 Jul 2016 11:45:57 -0700

> From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
> Sent: Friday, July 08, 2016 1:03 PM
> To: dhcwg <[email-masked]>
> Subject: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th
>
> Hi all,
>
> So the day finally has come. Authors working on RFC3315bis believe that after over two years of work, this document is ready for working group last call. This call initiates the working group last call on
> draft-ietf-dhc-rfc3315bis-05 [1]. Since this is a large document
> (130+ pages), there's upcoming meeting and a holiday period, chairs
> decided to do an extended last call that will last 4 weeks. Please
> post your comments by August 8th.

[...]

> appendices A anb B seems like a good place to start. If you like to
> see the list of tickets addressed, see [2]. Many smaller issues were

A couple of quick comments:

- Appendix A.  Changes since RFC3315

   Note: This appendix should be removed by the RFC-Editor when
   preparing the document for publication.

I don't think it a good idea to completely skip a section on changes
from the updated RFCs (this comment applies to Appendix B too).  In
its current form the change list is quite useless, but that doesn't
mean we can/should simply omit including a list of changes.  In fact,
IMO, a change list is even more important for such a huge document as
this one.

This comment is also related to the review process - as a voluntary
(possible) reviewer, it's very painful to (be asked to) read a change
list like this one: in some cases it simply refers to some ticket
number without saying what's changed, and in some cases some of the
changes are made moot because of some later changes (e.g., there are
some changes related to the delayed authentication protocol, but
change #48 makes them irrelevant).

I would strongly suggest introducing a more readable and well
organized "Changes since" appendices (which should stay on
publication).  That will also help entice more people to review, or at
least take a glace of, the doc.

--
JINMEI, Tatuya

---

From: tianxiang li <[email-masked]>
Date: Fri, 29 Jul 2016 14:41:25 +0800

A few quick comments below:

Throughout the document, “IAPREFIX option” and “IA Prefix option” are both
used (e.g. section 17.1.9.), should there be a unified expression?
Currently, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue uses the term
“IAPREFIX option” should we change it to “IA Prefix option”?

Some wording errors for Section 22 privacy considerations:

"This section focuses on the server considerations. For extended discussion
about privacy considerations for the client, see [RFC7824].
It(In) particular, Section 3 of said(the) document discuss(discusses)
various identifiers that could be misused to track the client."

Cheers,
Tianxiang