gmane.ietf.dhc

Re: Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

Bernie Volz (volz — 2012-05-25T10:45:20

If a client requests both IA_NA and IA_PD, here is what our server
(Cisco Prime Network Registrar does):

- If neither are possible:
- Top level option has Status Code with NoAddrsAvail
- IA_PA has Status Code with NoPrefixAvail
- If only IA_NA possible:
- IA_NA has binding information
- IA_PD has Status Code with NoPrefixAvail
- If only IA_PD possible:
- Top level option has Status Code with NoAddrsAvail
- IA_PD has binding information

My read of RFC 3315 says that the above is correct with respect to
IA_NA/IA_TA. (Note that you can replace IA_NA with IA_TA in the above,
or add IA_TA.) BTW, you would NEVER include NoAddrsAvail if no
IA_NA/IA_TA options.

My read of RFC 3633 says that the above is correct with respect to
IA_PD.

A client should only treat a message with Status Code with NoAddrsAvail
to have "failed" with respect to IA_NA/IA_TA. Not, IA_PD. This is
exactly what we are suggesting the behavior to be in the draft.

While I agree that this Status Code difference is rather odd and I had
pus

Re: Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

Bernie Volz (volz — 2012-05-25T10:29:03

BTW - we really should be referencing
draft-ietf-dhc-dhcpv6-stateful-issues-00. I hope that is the draft that
you looked at.

 

client can only be associated with one server at a time. 

 

We are pretty much saying that, per interface, a client is associated
with one server. There isn't anything to prohibit multiple servers, but
without some additional work (which I mentioned at the DHC WG meeting in
Paris) to support multiple administrative domains, it is not possible
for a client to know whether it is in ONE or MULTIPLE administrative
domains. And, in probably 99.9% of the cases, it is in a SINGLE
administrative domain. So, let's make sure that things work well in that
environment before worrying about the 0.1% (perhaps I should have said
99% and 1% based on the recent "Occupy" movements).

 

1.       Does it need to wait for the next renew time to get expired
before it can ask IA_PD along.? 

 

Yes. Best practice is that it should renew early and renew what it has
and also ask for the IA_PD. But, the

Re: Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

Gaurav Halwasia (ghalwasi — 2012-05-25T08:10:08

Thanks Bernie for clarification.
 
<snip>
I believe, it is possible that a particular server is willing to offer
only a subset of IA_'s which has been requested. In that case, what's
the use of including the other IA_ in the subsequent renew/rebind. As in
this case server will anyway only renew only one IA_. ? Are we
suggesting that a client at any given point of time should only be
talking to one server after the advertise is accepted.
 
BV> What harm is there in continuing to include this in the subsequent
operations? If the server's policy prohibits returning addresses or
delegated prefixes for these other IA types, there is no harm. The main
assumption is that clients are in a single administrative domain and
thus talking to another server will be unlikely to help (except of
course in the case of misconfiguration, but better that the issue is
detected early and dealt with).

</snip>

 

[Gaurav] I don't see any harm in including not assigned IA_'s in
subsequent renew and rebind.  I wanted to clarify that

Re: Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

Stephen Jacob — 2012-05-25T06:37:47

This is actually extremely interesting to me. I believe there remains
even further confusion with the cited section. I will explain the
issues I ran into recently below the quoted context!

On Thu, May 24, 2012 at 02:29:52PM -0500, Bernie Volz (volz) wrote:
...

Now, here's where it gets even more convoluted:

(I don't know if deconfusing this convolutedness is in scope for this
draft, but I'd very much like any opinions/solutions from other
implementors even if it is not).

-----

As mentioned above, in RFC 3315, section 17.1.3, it says:

  "The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user."

and in section 17.2.2 it says:

  "If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
   code NoAddrsAvail

Re: Question on DHCPv6 / RFC3315

Andre Kostur — 2012-05-25T01:20:52

I would say no.  By changing from DHCPv6 Enabled to Static, it should no
longer be doing DHCP.

On Thu, May 24, 2012 at 11:40 AM, a r pradeep <pradeepar< at >gmail.com> wrote:

Question on DHCPv6 / RFC3315

a r pradeep — 2012-05-24T18:40:32

Hello All

Had a question on RFC 3315, Section 18.1.2 Creation and Transmission of
Confirm messages

When a client changes its configuration from dhcpv6 enabled to static, is
this considered as moving to new link and is the client required to send
out a Confirm message ?

Thanks
pradeep
_______________________________________________
dhcwg mailing list
dhcwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Re: Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

Bernie Volz (volz — 2012-05-24T19:29:52

Hi and thanks for reading and commenting!

 

Comments below (BV>).

 

-          Bernie

 

From: dhcwg-bounces< at >ietf.org [mailto:dhcwg-bounces< at >ietf.org] On Behalf
Of Gaurav Halwasia (ghalwasi)
Sent: Thursday, May 24, 2012 11:03 AM
To: dhcwg< at >ietf.org
Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

 

I have read this informational draft and I have couple of comments so
far.

 

1.)Section 3.1

   Replace Section 17.1.3
<http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se
ction-17.1.3> : (existing errata)
 
 
      The client MUST ignore any Advertise message that includes a
Status
      Code option containing the value NoAddrsAvail, with the exception
      that the client MAY display the associated status message to the
      user.
 
   With:
 
 
      The client MUST ignore any IAs in an Advertise message that
      includes a Status Code option containing the value NoAddrsAvail,
      with the exception that the client MAY display the associated
      status me

Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

Gaurav Halwasia (ghalwasi — 2012-05-24T15:03:25

I have read this informational draft and I have couple of comments so
far.

 

1.)Section 3.1

   Replace Section 17.1.3
<http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se
ction-17.1.3> : (existing errata)
 
 
      The client MUST ignore any Advertise message that includes a
Status
      Code option containing the value NoAddrsAvail, with the exception
      that the client MAY display the associated status message to the
      user.
 
   With:
 
 
      The client MUST ignore any IAs in an Advertise message that
      includes a Status Code option containing the value NoAddrsAvail,
      with the exception that the client MAY display the associated
      status message to the user. An Advertise message without any IA
      options MUST be ignored.

 

Is this only applicable to IA_NA.? I guess in case client sends SOLICIT
with both IA_NA and IA_PD. Then in that case I guess we should mention
"NoPrefixAvail" as well.
 
2.) Section 3.6
   Proposed solution: the client should keep a sing

I-D Action: draft-ietf-dhc-host-gen-id-02.txt

2012-05-23T01:01:43

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

Title           : Prefix Assignment in DHCPv6
Author(s)       : Sheng Jiang
                          Frank Xia
                          Behcet Sarikaya
Filename        : draft-ietf-dhc-host-gen-id-02.txt
Pages           : 10
Date            : 2012-05-22

   This document introduce a procedure for configuring hosts' IPv6
   address which the prefix is assigned from a DHCPv6 server through
   DHCPv6 protocol while the interface identifiers are independently
   generated by the hosts.  The method is applicable to
   Cryptographically Generated Addresses (CGA), and other IPv6 addresses
   with host-generated interface identifiers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-host-gen-id-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Interne

New IETF I-D: draft-gont-opsec-dhcpv6-shield-00.txt

Fernando Gont — 2012-05-18T23:33:56

Folks,

We have published a new IETF I-D entitled: "DHCPv6-Shield: Protecting
Against Rogue DHCPv6 Servers". It is analogous to the RA-Guard (RFC
6105) mechanism currently employed for mitigating RA-based attacks.

The I-D is available at:
<http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>

I'm not sure in which wg I'd be pursuing this effort (v6ops, opsec, or
dhcwg). If there's interest in this wg, it could be done here. However,
in any case discussion of this document within dhcwg would be welcome.

Thanks!

Best regards,
Fernando




-------- Original Message --------
Subject: New Version Notification for draft-gont-opsec-dhcpv6-shield-00.txt
Date: Thu, 17 May 2012 22:26:10 -0700
From: internet-drafts< at >ietf.org
To: fgont< at >si6networks.com

A new version of I-D, draft-gont-opsec-dhcpv6-shield-00.txt has been
successfully submitted by Fernando Gont and posted to the IETF repository.

Filename: draft-gont-opsec-dhcpv6-shield
Revision: 00
Title: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Se

RFC 6603 on Prefix Exclude Option for DHCPv6-based PrefixDelegation

2012-05-15T22:17:55

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6603

        Title:      Prefix Exclude Option for DHCPv6-based 
                    Prefix Delegation 
        Author:     J. Korhonen, Ed.,
                    T. Savolainen, S. Krishnan,
                    O. Troan
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2012
        Mailbox:    jouni.nospam< at >gmail.com, 
                    teemu.savolainen< at >nokia.com, 
                    suresh.krishnan< at >ericsson.com,
                    ot< at >cisco.com
        Pages:      10
        Characters: 19485
        Updates:    RFC3633

        I-D Tag:    draft-ietf-dhc-pd-exclude-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6603.txt

This specification defines an optional mechanism to allow exclusion
of one specific prefix from a delegated prefix set when using DHCPv6-based
prefix delegation.  The new mechanism updates RFC 3633.  [STANDARDS-TRACK]

This document is a product of

Re: WGLC: draft-ietf-dhc-secure-dhcpv6

GangChen — 2012-05-13T01:08:50

I think the draft is in a good shape.
Support to move forward

Many thanks

Gang

2012/5/7, Ted Lemon <Ted.Lemon< at >nominum.com>:

Document Action: 'Description of Cisco Systems' SubnetAllocationOption for DHCPv4' to InformationalRFC(draft-ietf-dhc-subnet-alloc-13.txt)

The IESG — 2012-05-11T19:30:00

The IESG has approved the following document:
- 'Description of Cisco Systems' Subnet Allocation Option for DHCPv4'
  (draft-ietf-dhc-subnet-alloc-13.txt) as Informational RFC

This document is the product of the Dynamic Host Configuration Working
Group.

The IESG contact persons are Ralph Droms and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/




Technical Summary

  This document defines a new DHCP option which is passed between the
  DHCP Client and the DHCP Server to request dynamic allocation of a
  subnet, give specifications of subnet(s) allocated, and report usage
  statistics.  This memo documents the current usage of the option in
  agreement with [RFC3942], which declares that any pre-existing usages
  of option numbers in the range 128 - 223 should be documented and the
  working group will try to officially assign those numbers to those
  options.

Working Group Summary

   There was nothing controversial about this document.  The

Re: Fw: WGLC: draft-ietf-dhc-secure-dhcpv6

Liubing (Leo — 2012-05-11T03:21:13

+1
I also support this draft to move forward.
The draft provides a practical approach to secure the DHCPv6 interaction with using the mature CGA mechanisms.
B.R.
Bing
From: dhcwg-bounces< at >ietf.org [mailto:dhcwg-bounces< at >ietf.org] On Behalf Of Di Ma
Sent: Tuesday, May 08, 2012 11:48 AM
To: DHC WG
Subject: [dhcwg] Fw: WGLC: draft-ietf-dhc-secure-dhcpv6

Considering DHCPv6 is somehow of big importance in the era of IPv6, CGA, as a well-fashioned IPv6 address, is going to protect DHCPv6 away from various attacks. Some efforts on the standardization of related techniques should be made.
I am in favor of advancing this document.

________________________________
Di Ma
CNNIC Advanced Research Department
___________________________________________________
China Internet Network Information Center
Tel: (8610)-58813216
Https://www.cnnic.cn
Add: 4, South 4th Street, Zhongguancun
Haidian District, Beijing
P.R.China 100190
POB: Beijing 349, Branch 6
____________________________________________________

From: Ted Lemon<mail

Re: WGLC: draft-ietf-dhc-secure-dhcpv6

Fuyu (Eleven — 2012-05-10T09:19:56

Hi all,

  I am in favor of advancing this draft.
  Thanks

  Yu



-----Original Message-----
From: dhcwg-bounces< at >ietf.org [mailto:dhcwg-bounces< at >ietf.org] On Behalf Of Ted Lemon
Sent: Monday, May 07, 2012 12:37 PM
To: DHC WG
Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6

In the Paris meeting a show of hands indicated that the group favored bringing this document to last call.   So this is the last call for this document.   If you are in favor of advancing it, and have read it, please say so.   If you think it needs work, please send text or suggestions.   If you don't think it should advance, please say so.

We will determine consensus on May 21.

_______________________________________________
dhcwg mailing list
dhcwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Re: Call foradoption:draft-yeh-dhc-dhcpv6-authorization-opt

Ted Lemon — 2012-05-09T15:08:02

Nine people were in favor of adopting this work and said so on the mailing list.   Nobody spoke to oppose doing the work.   So there is consensus to adopt it.   Leaf agreed to change the name of the draft to make it more clear that it's about radius options.

Oops.   I just realized that I closed the call for adoption five days early.   If somebody had objections and didn't voice them because of this, please let me know.

I'm assuming nobody did, but this was a mistake, and I don't want to just leave it unacknowledged or miss the opportunity to correct it.   Sorry about this!

_______________________________________________
dhcwg mailing list
dhcwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Fw: WGLC: draft-ietf-dhc-secure-dhcpv6

Di Ma — 2012-05-08T03:48:19

Considering DHCPv6 is somehow of big importance in the era of IPv6, CGA, as a well-fashioned IPv6 address, is going to protect DHCPv6 away from various attacks. Some efforts on the standardization of related techniques should be made. 
I am in favor of advancing this document.




Di Ma 
CNNIC Advanced Research Department
___________________________________________________
China Internet Network Information Center
Tel: (8610)-58813216
Https://www.cnnic.cn
Add: 4, South 4th Street, Zhongguancun
Haidian District, Beijing
P.R.China 100190
POB: Beijing 349, Branch 6
____________________________________________________

From: Ted Lemon
Date: 2012-05-07 12:37
To: DHC WG
Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6
In the Paris meeting a show of hands indicated that the group favored bringing this document to last call.   So this is the last call for this document.   If you are in favor of advancing it, and have read it, please say so.   If you think it needs work, please send text or s

WGLC: draft-ietf-dhc-secure-dhcpv6

Ted Lemon — 2012-05-07T04:37:18

In the Paris meeting a show of hands indicated that the group favored bringing this document to last call.   So this is the last call for this document.   If you are in favor of advancing it, and have read it, please say so.   If you think it needs work, please send text or suggestions.   If you don't think it should advance, please say so.

We will determine consensus on May 21.

Re: Call for adoption: draft-jiang-addr-registration

Ted Lemon — 2012-05-07T04:34:50

We will determine consensus on May 1, 2012.

Nine were in favor of adopting, none opposed, so the working group has adopted this as a work item.

_______________________________________________
dhcwg mailing list
dhcwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-00.txt

2012-05-07T03:28:57

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

Title           : Issues with multiple stateful DHCPv6 options
Author(s)       : Ole Troan
                          Bernie Volz
Filename        : draft-ietf-dhc-dhcpv6-stateful-issues-00.txt
Pages           : 8
Date            : 2012-05-06

   Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
   with the expectation that additional stateful DHCPv6 options would be
   developed.  IPv6 Prefix Options for Dynamic Host Configuration
   Protocol (DHCP) version 6 shoe-horned the new options for Prefix
   Delegation into DHCPv6.  Implementation experience of the CPE model
   described in has shown multiple issues with the DHCPv6 protocol in
   supporting multiple stateful options.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-00.txt

Internet-Drafts are also av

Re: Call for adoption:draft-yeh-dhc-dhcpv6-authorization-opt

Ted Lemon — 2012-05-04T19:44:47


Nine people were in favor of adopting this work and said so on the mailing list.   Nobody spoke to oppose doing the work.   So there is consensus to adopt it.   Leaf agreed to change the name of the draft to make it more clear that it's about radius options.

Leaf, please publish a -00 version as a working group draft when you are ready.

Thanks!