Bernie Volz (volz | 23 May 2013 22:25
Picon
Favicon

IETF-87 (Berlin) Call for Agenda Items

Hi:

 

While perhaps a bit early, we are starting the call for agenda items for the dhc wg meeting. And, as late June and July tend to be a prime vacation periods, perhaps best to get people to start thinking about this now.

 

We have asked for two slots:

-          One 2 ½ hour slot for the usual dhc wg meeting

-          One 1 hour slot as a joint meeting with the sunset4 wg to discuss http://tools.ietf.org/html/draft-perreault-sunset4-noipv4

 

If you have a draft you would like to discuss, please send your request for agenda time to the dhc chairs. Please include:

-          the title and file name of the draft

-          a brief summary of why it needs to be discussed

-          the speakers name (and email)

-          and how much time you need will need for presentation and anticipated discussion.

 

We will give priority, if needed, to requests for documents that are currently working group items or were actively discussed on the mailing list.

 

We do expect to spend some time discussing a re-charter and also a DHCP directorate (more on this before the meeting).

 

Please have agenda items to us by 2013-07-01 (Monday) and also note the following deadlines for IETF87:

 

2013-07-08 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00

2013-07-15 (Monday): Internet Draft final submission cut-off by UTC 24:00

 

For full details about the meeting, see http://www.ietf.org/meetings/87/.

 

-          Tomek & Bernie

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Ted Lemon | 22 May 2013 20:19

Re: Question about RFC5908

On May 22, 2013, at 1:52 PM, Andre Kostur <akostur <at> incognito.com> wrote:
> So it's trying to acknowledge that there may be a bunch of other,
> unrelated suboptions stuck into this option?   Wait... are we possibly
> arguing over a typo?  If we re-read the problematic statement as
> "Instead, it contains one _of_ several suboptions that carry..." that
> seems to make more sense.

It might have been better to say "one or more," but the meaning of the sentence is correct, and your proposed
change would make it incorrect.   The option can contain any number of suboptions greater than zero.  
Exactly one of those suboptions can be a time source suboption.   That's what the text says, and that's what
the text was intended to say.   There is no error or ambiguity here.
François-Xavier Le Bail | 21 May 2013 09:44
Picon
Favicon

Question about RFC5908

[Adding dhcwg and RFC authors]

Hello,

About RFC5908, "Network Time Protocol (NTP) Server Option for DHCPv6".

Section 4 says: 
The option itself does not contain any value.  Instead, it contains
one or several suboptions that carry NTP server or SNTP server
location.  This option MUST include one, and only one, time source
suboption. 

(http://tools.ietf.org/html/rfc5908#section-4)

It seems to me contradictory:
- The option itself [...]. Instead, it contains one or several suboptions [...]
- This option MUST include one, and only one, time source suboption.

Did I miss something ?

Best regards,

Francois-Xavier le Bail
SPHICAS, PHIL G | 17 May 2013 17:55
Picon
Favicon

Source address in IP header for DHCPREQUEST generated during REBINDING state?

Hello,

What is the correct source IP address for a DHCPREQUEST generated during REBINDING state? Should it be the
unicast IP, or 0.0.0.0?

I'm not quite clear on this after combing through RFC 2131 .. any pointers would be appreciated.

RFC 2131
4.3.2 DHCPREQUEST message 
DHCPREQUEST generated during REBINDING state

This message MUST be broadcast to the 0xffffffff IP broadcast address.

-- This doesn't specify the source IP

RFC 2131
4.1 Constructing and sending DHCP messages

DHCP clients MUST use the IP address provided in the 'server identifier' option for any unicast requests to
the DHCP server.

-- This is a broadcast request, not a unicast request

DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source
address field in the IP header set to 0.

-- This is after the client has obtained an IP address

Thanks,
Phil
ian.farrer | 16 May 2013 19:16
Picon

Mail regarding draft-ietf-dhc-dhcpv4-over-dhcpv6

Hi,

I was just looking through this draft again and one thing that I noticed is that the RFC4361 compliant behaviour is only mandated for clients. There is no mention of compliance for the server. Surely, it's needed for both?

Cheers,
Ian
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
gvithal . | 15 May 2013 15:00
Picon

Echoing back options in server response

Does RFC 3315 mandate that DHCPv6 server should echo back all options in the client request message in its response even if the server does not support a specific option.
For example, if the client message contains vendor-specific information option (section 22.17 rfc 3315), does the server need to echo back the same option in its response even if does not support that option.

Thanks,
Prasad
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Bernie Volz (volz | 13 May 2013 23:31
Picon
Favicon

Re: WG Adoption Call RESULT - draft-bhandari-dhc-access-network-identifier-04

Hi:

 

Sorry for the delay in announcing the result … we feel that this document has sufficient support to adopt in the working group. And, as there isn’t another home for this work within the IETF, it is appropriate for the DHC WG to take it on.

 

Authors, please publish a WG document as soon as you can.

 

-          Tomek & Bernie

 

From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 17, 2013 9:33 AM
To: dhcwg <at> ietf.org
Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013

 

Hi all:

 

The authors have requested a call for adoption by the WG for draft-bhandari-dhc-access-network-identifier-04.

 

This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete on May 2nd, 2013.

 

Note that the 04 draft was just published and has redesigned options to better follow the option guidelines.

 

The HTML version of the document can be viewed at http://tools.ietf.org/html/draft-bhandari-dhc-access-network-identifier-04.

 

Regards,

Tomek & Bernie

 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Bernie Volz (volz | 13 May 2013 20:04
Picon
Favicon

draft-ietf-dhc-dhcpv6-stateful-issues-04.txt

Hi:

 

This is an updated version of this document. It includes a few minor changes from the WG last call and is there mostly to restore this document as it has expired a few days ago.

 

I still have a bunch of the comments from the WG Last Call in January/February to address.

 

There is also one key issue that will need some discussion from the WG. In particular, handling of Rebind requests.

 

One major flaw with respect to the Rebind message handling in RFC 3315 and this draft is that as the client has sent the Rebind to multiple servers, all of which could respond, there is no way for a particular server to know whether its Reply will be accepted by the client. This is essentially the same issue with using Rapid Commit in a Solicit when there are multiple servers available.

 

I think the Rebind processing should essentially be changed so that a server will either return everything the client requested to be rebound (and nothing more) or nothing (in which case it returns NoBinding status for all bindings).

 

If the server is willing to extend (or grant) the existing leases, the Rebind is fine. If the server is unwilling or unable, then it should force the client back into a Request phase as described in RFC 3315 section  18.1.8. That 18.1.8 section is also the only place a NoBinding status appears to be mentioned in terms of the Rebind.

 

-          Bernie

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
internet-drafts | 13 May 2013 19:55
Picon
Favicon

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


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-04.txt
	Pages           : 10
	Date            : 2013-05-13

Abstract:
   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 [RFC6204] has shown multiple issues with the DHCPv6
   protocol in supporting multiple stateful options.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-stateful-issues-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
internet-drafts | 13 May 2013 10:39
Picon
Favicon

I-D Action: draft-ietf-dhc-v4configuration-00.txt


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           : Provisioning IPv4 Configuration Over IPv6 Only Networks
	Author(s)       : Branimir Rajtar
                          Ian Farrer
	Filename        : draft-ietf-dhc-v4configuration-00.txt
	Pages           : 13
	Date            : 2013-05-13

Abstract:
   As IPv6 becomes more widely adopted, some service providers are
   taking the approach of deploying IPv6 only networks, without dual-
   stack functionality for IPv4.  However, access to IPv4 based services
   is still an ongoing requirement and approaches such as IPv4-in-IPv6
   softwire tunnels are being developed to meet this need.

   In order to provision end-user's hosts with the necessary IPv4
   configuration, a number of different mechanisms have been proposed.
   This memo discusses the benefits and drawbacks of each, with the aim
   of recommending a single approach as the basis for future work.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
RFC Errata System | 9 May 2013 06:16
Favicon

[Technical Errata Reported] RFC6656 (3617)

The following errata report has been submitted for RFC6656,
"Description of Cisco Systems' Subnet Allocation Option for DHCPv4".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6656&eid=3617

--------------------------------------
Type: Technical
Reported by: Dushyant Raghuvanshi <draghuva <at> cisco.com>

Section: 3.2

Original Text
-------------
Len = Length of the suboption (min. length of 8) (1 octet)

Corrected Text
--------------
Len = Length of the suboption (min. length of 1) (1 octet)

Notes
-----
RFC 6656 suggests that a DHCP Client MAY request list of previously allocated subnets from the DHCP Server
in case of recovering from a restart if the Client does not have local storage in order to retain the
information itself. But there will be cases when Server does not have any information to send back (this
could be a new Client or this Client never spoke to this Server before). In this case, DHCP Server may decide
to remain silent and discard the request. This approach will make it difficult for DHCP Client to decide if
request could not reach to Server or Server did not have any information to send back. A possible approach
could be to send the OFFER back to Client with Subnet-Information Suboption (without Subnet Prefix
Information Block) in it. So that Client can proceed by making
  a request to allocate new subnets. This would require to reduce the minimum length of Subnet-Information
Suboption to 1 (just include flags). Section 6 would require to be updated as well t
 o reflect the new behavior (to respond).

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6656 (draft-ietf-dhc-subnet-alloc-13)
--------------------------------------
Title               : Description of Cisco Systems' Subnet Allocation Option for DHCPv4
Publication Date    : July 2012
Author(s)           : R. Johnson, K. Kinnear, M. Stapp
Category            : INFORMATIONAL
Source              : Dynamic Host Configuration
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

Gmane