[dhcwg] FW: dhcwg Digest, Vol 159, Issue 22

[Srinivasa Rao Nalluri <[e-mail]>]

Hi Francis,

Thank you for review and comments. Please see my response inline prefixed
with [Srinivas]


I red draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt
(it is in the agenda this afternnon) and I found two loose references to RFC
7296 (IKEv2) section 3.6 (CERT payload).

I have two concerns about this:
 - certificates can be very large, at least larger than a DHCPv4 option
  can carry

[Srinivas] We already have an RFC that talks about encoding larger content
in DHCPv4 option. So, I mentioned following in section 4.
   "Maximum possible value of DHCPv4 "option-len" is 255.
LWM2M-server-certificate MAY be of length more than 255.  To accommodate
larger
   certificate, DHCP server SHOULD follow encoding as mentioned in
[RFC3396]."

 - as IKEv2 is over UDP too this problem is addressed in RFC 7296 by
  allowing many different "encodings" (currently 15 in the IANA
  registry).

So I am afraid authors just took a good text about certificate transport
(BTW I'd pick the same one so my concern is not about the choice) but missed
to add an additional statement about application.

I propose:
 - add something about the encoding byte so nobody will forget to read
  RFC 7296 and for instance put a X.509 certificate as the whole content
[Srinivas] I need a bit more clarity on this comment. Encoding byte is
explained in RFC 7296. It will be same even if we explain in our draft. Is
that ok to repeat details of "cert encoding" byte of section 3.6, RFC7296? 
Or 
Do you say that option format defined in section 3.2 "DHCPv6 option for
LWM2M server certificate" should include "cert encoding" byte and same
should be explicitly explained in our draft?
I see later makes more sense.

 - make a few encodings mandatory to support (*)
[Srinivas] I will check what formats/encodings make more sense in LWM2M
deployments and I will add them as mandatory list in next version of draft.

Thanks 
Srinivas

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Wednesday, July 19, 2017 4:13 PM
To: [e-mail]
Subject: dhcwg Digest, Vol 159, Issue 22

Send dhcwg mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of dhcwg digest..."


Today's Topics:

   1. draft-moses-dmm-dhcp-ondemand-mobility - minor comments.
      (W?odzimierz Wencel)
   2. Re: I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions
      about Solicit Prefix Delegation (Alexandre Petrescu)
   3. Re: I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions
      about Solicit Prefix Delegation (Ted Lemon)
   4. Re: I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions
      about Solicit Prefix Delegation (Alexandre Petrescu)
   5. about draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt
      (Francis Dupont)


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

Message: 1
Date: Wed, 19 Jul 2017 11:02:23 +0200
From: W?odzimierz Wencel <[e-mail]>
To: [e-mail]
Subject: [dhcwg] draft-moses-dmm-dhcp-ondemand-mobility - minor
	comments.
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"

There are two minor issues in the draft.

1. in section 3 and section 4 usage of status code NoAddrsAvail should be
replaced with NoPrefixAvail

2. Anchor Preference Option should be formatted as IA Prefix Option (3315):
- valid-lifetime value is missing
- ip6-prefix should have fixed length to keep it easy to parse instead of:

    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_ANCHOR_PREFERENCE      |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      preferred-lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | prefix6len    |          ipv6-prefix                          |
   +-+-+-+-+-+-+-+-+       (variable length)                       |
   .                                                               .
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  IAanchor_preference-options                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

should 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_ANCHOR_PREFERENCE      |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      preferred-lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        valid-lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | prefix6len    |          ipv6-prefix                          |
   +-+-+-+-+-+-+-+-+          (16 octets)                          |
   .                                                               .
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  IAanchor_preference-options                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Thanks,
W?odek Wencel
ISC
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/dhcwg/attachments/20170719/3b6a1f2
4/attachment.html>

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

Message: 2
Date: Wed, 19 Jul 2017 11:10:25 +0200
From: Alexandre Petrescu <[e-mail]>
To: Ted Lemon <[e-mail]>, V?zdal Ale?
	<[e-mail]>
Cc: dhcwg <[e-mail]>, "Bernie Volz (volz)" <[e-mail]>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt -
	questions about Solicit Prefix Delegation
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=utf-8; format=flowed

Ted,

Let me explain.  I no longer have a request for the spec 3315bis.  Sorry for
the intrusion.

Le 18/07/2017 ? 11:07, Ted Lemon a ?crit :
> He later said that he'd observed this behavior when using the ISC 
> DHCP client.   My theory is that this is an artifact of the way the 
> ISC DHCP client transmits packets on the network, and not a problem 
> with the tunneling protocol.   It would be nice to validate that 
> conjecture.

We work on this conjencture, but it takes time, because it involves many
people, I am the only who speaks, and some times wrongly.  Now I prefer to
stay silent until I get some resolution to talk about.

Until then, all I can say is that I have packet dumps that show
encapsulation, and ICMP hoplimit exceeded, and that the DHCP Solicit had
hoplimit 1.  It is however not clear whether or not that's anybody's fault.

This is not a matter of someone's fault; the goal is to make it work.

I am sorry for the confusion this may have created.

Alex



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

Message: 3
Date: Wed, 19 Jul 2017 11:52:35 +0200
From: Ted Lemon <[e-mail]>
To: Alexandre Petrescu <[e-mail]>
Cc: V?zdal Ale? <[e-mail]>, dhcwg <[e-mail]>,
	"Bernie Volz (volz)" <[e-mail]>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt -
	questions about Solicit Prefix Delegation
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset="utf-8"

No worries.   Have you tried compiling with USE_SOCKETS?   Does that
produce the same result?

On Wed, Jul 19, 2017 at 11:10 AM, Alexandre Petrescu <
[e-mail]> wrote:

> Ted,
>
> Let me explain.  I no longer have a request for the spec 3315bis.  
> Sorry for the intrusion.
>
> Le 18/07/2017 ? 11:07, Ted Lemon a ?crit :
>
>> He later said that he'd observed this behavior when using the ISC DHCP
>> client.   My theory is that this is an artifact of the way the ISC DHCP
>> client transmits packets on the network, and not a problem with the
>> tunneling protocol.   It would be nice to validate that conjecture.
>>
>
> We work on this conjencture, but it takes time, because it involves 
> many people, I am the only who speaks, and some times wrongly.  Now I 
> prefer to stay silent until I get some resolution to talk about.
>
> Until then, all I can say is that I have packet dumps that show 
> encapsulation, and ICMP hoplimit exceeded, and that the DHCP Solicit 
> had hoplimit 1.  It is however not clear whether or not that's anybody's
fault.
>
> This is not a matter of someone's fault; the goal is to make it work.
>
> I am sorry for the confusion this may have created.
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/dhcwg/attachments/20170719/aad17a7
6/attachment.html>

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

Message: 4
Date: Wed, 19 Jul 2017 11:57:49 +0200
From: Alexandre Petrescu <[e-mail]>
To: Ted Lemon <[e-mail]>
Cc: V?zdal Ale? <[e-mail]>, dhcwg <[e-mail]>,
	"Bernie Volz (volz)" <[e-mail]>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt -
	questions about Solicit Prefix Delegation
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=utf-8; format=flowed

Le 19/07/2017 ? 11:52, Ted Lemon a ?crit :
> No worries.   Have you tried compiling with USE_SOCKETS?   Does that 
> produce the same result?

Yes and results are different but still not satisfactorily overall.

(FWIW #define USE_SOCKETS 1 goes in build/includes/config.h)

Alex

> 
> On Wed, Jul 19, 2017 at 11:10 AM, Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>>
wrote:
> 
>     Ted,
> 
>     Let me explain.  I no longer have a request for the spec 3315bis.
Sorry
>     for the intrusion.
> 
>     Le 18/07/2017 ? 11:07, Ted Lemon a ?crit :
> 
>         He later said that he'd observed this behavior when using the
>         ISC DHCP client.   My theory is that this is an artifact of the
>         way the ISC DHCP client transmits packets on the network, and
>         not a problem with the tunneling protocol.   It would be nice to
>         validate that conjecture.
> 
> 
>     We work on this conjencture, but it takes time, because it involves
many
>     people, I am the only who speaks, and some times wrongly.  Now I
prefer
>     to stay silent until I get some resolution to talk about.
> 
>     Until then, all I can say is that I have packet dumps that show
>     encapsulation, and ICMP hoplimit exceeded, and that the DHCP Solicit
had
>     hoplimit 1.  It is however not clear whether or not that's anybody's
>     fault.
> 
>     This is not a matter of someone's fault; the goal is to make it work.
> 
>     I am sorry for the confusion this may have created.
> 
>     Alex
> 
> 



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

Message: 5
Date: Wed, 19 Jul 2017 12:26:08 +0200
From: Francis Dupont <[e-mail]>
To: [e-mail]
Subject: [dhcwg] about
	draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt
Message-ID: <[e-mail]>

I red draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt
(it is in the agenda this afternnon) and I found two loose references to RFC
7296 (IKEv2) section 3.6 (CERT payload).

I have two concerns about this:
 - certificates can be very large, at least larger than a DHCPv4 option
  can carry

 - as IKEv2 is over UDP too this problem is addressed in RFC 7296 by
  allowing many different "encodings" (currently 15 in the IANA
  registry).

So I am afraid authors just took a good text about certificate transport
(BTW I'd pick the same one so my concern is not about the choice) but missed
to add an additional statement about application.

I propose:
 - add something about the encoding byte so nobody will forget to read
  RFC 7296 and for instance put a X.509 certificate as the whole content

 - make a few encodings mandatory to support (*)

Thanks

[e-mail]

PS (*): if it makes sense in environments where LWM2M is/will be deployed I
highly recommend the hash and URL formats. BTW they were introduced in IKEv2
so in RFC 7296 a notify was added to indicate support.
This is no necessary for this I-D and of course it avoids large payload
problems (it was designed with this goal).



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

Subject: Digest Footer

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg


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

End of dhcwg Digest, Vol 159, Issue 22
**************************************