Is there any interest in a live webcast of the DHC wg meeting in Vancouver? We've never done this before, and I've never asked, but it's at least potentially on offer, so if there are people who can't attend in Vancouver but would like to participate, please let us know.
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 : Forcerenew Nonce Authentication
Author(s) : David Miles
Wojciech Dec
James Bristow
Roberta Maglione
Filename : draft-ietf-dhc-forcerenew-nonce-07.txt
Pages : 13
Date : 2012-06-14
Abstract:
Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the
reconfiguration of a single host by forcing the DHCP client into a
Renew state on a trigger from the DHCP server. In Forcerenew Nonce
Authentication the server sends a nonce to the client in the initial
DHCP ACK that is used for subsequent validation of a FORCERENEW
message. This document updates RFC 3203.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-forcerenew-nonce
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-forcerenew-nonce-07
A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-dhc-forcerenew-nonce-07
(Continue reading)
Hi,
I read draft-ietf-dhc-option-guidelines-08 as a possible consumer
(writing a draft about a new DHCPv6 option). I have two questions...
1. The draft doesn't talk about options with size zero. Are they good or
evil? I would have expected a subsection of section 5 to talk about
them. There's one in RFC3315: OPTION_RAPID_COMMIT.
2. Section 14 contains the following:
It is a frequent mistake of option draft authors, then, to create
text that implies that a server will simply provide the new option,
and clients will digest it. Generally, it's best to also specify
that clients MUST place the new option code on the relevant list
option, clients MAY include the new option in their packets to
servers with hints as to values they desire, and servers MAY respond
with the option contents (if they have been so configured).
I can't parse the second sentence. What should I write in my draft? I
guess it should start with "Clients MUST place the new option code ..."
but I can't finish the sentence. What's the relevant list option? (My
new option has no value, as you might have guessed.)
Other than that, everything was clear.
Thanks,
Simon
--
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
(Continue reading)
We have zero-length option for both v4 (rfc 4039) and v6 (3315) rapid commit. So something should be said to allow these. Regarding that text, it means for v4 client must include option code in Parameter Request List option (55) and for v6 in the Option Request Option (oro). While I can understand the shorthand, this is one area where the document best be explicit!! - Bernie Sent from my iPad On Jun 19, 2012, at 10:16 AM, "Simon Perreault" <simon.perreault <at> viagenie.ca> wrote: > Hi, > > I read draft-ietf-dhc-option-guidelines-08 as a possible consumer (writing a draft about a new DHCPv6 option). I have two questions... > > 1. The draft doesn't talk about options with size zero. Are they good or evil? I would have expected a subsection of section 5 to talk about them. There's one in RFC3315: OPTION_RAPID_COMMIT. > > 2. Section 14 contains the following: > > It is a frequent mistake of option draft authors, then, to create > text that implies that a server will simply provide the new option, > and clients will digest it. Generally, it's best to also specify > that clients MUST place the new option code on the relevant list > option, clients MAY include the new option in their packets to > servers with hints as to values they desire, and servers MAY respond > with the option contents (if they have been so configured).(Continue reading)
On 2012-06-19 10:26, Bernie Volz (volz) wrote: > We have zero-length option for both v4 (rfc 4039) and v6 (3315) rapid > commit. So something should be said to allow these. > > Regarding that text, it means for v4 client must include option code > in Parameter Request List option (55) and for v6 in the Option > Request Option (oro). While I can understand the shorthand, this is > one area where the document best be explicit!! Thanks, much clearer. But doesn't the draft only apply to DHCPv6? Simon -- -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca
Hi Ted, Some responses inline. On May 31, 2012, at 4:43 PM, Ted Lemon wrote: > There are still a few problems with this draft. The first is that it uses a nonstandard and somewhat odd encoding to deliver the URI and Lifetime values. These should simply be delivered as separate options, leaving out the whole Luritype complication. The argument might be raised that the Luritype field provides some sort of future-proofing, but this future-proofing can as easily be attained with another DHCP option code, so it's unnecessary. My understanding is that the option is encoded this way both for extensibility and because the Valid-For parameter is solely a property of the URI. Surely this is not the only instance of a DHCP option with a sub-option? It may have been before I was paying attention, but I get the impression that related ground has already been trod in DHC, given that it also came up in GEOPRIV. http://www.ietf.org/mail-archive/web/geopriv/current/msg08451.html > > Secondly, this text ought to be expanded: > >> The choice of the Valid-For value is a policy decision for the >> operator of the DHCP server. Like location URIs themselves, it can >> be statically configured on the DHCP server or provisioned >> dynamically (via an out-of-band exchange with a Location Information >> Server) as requests for location URIs are received. > > To: >(Continue reading)
On Jun 22, 2012, at 3:59 PM, Alissa Cooper wrote: > My understanding is that the option is encoded this way both for extensibility and because the Valid-For parameter is solely a property of the URI. Surely this is not the only instance of a DHCP option with a sub-option? What's in the draft is not suboptions—it's a whole special format requiring new code on all servers that implement it. Suboptions don't exist in DHCPv6—just encapsulations of regular options, which I don't think make sense here either. > It may have been before I was paying attention, but I get the impression that related ground has already been trod in DHC, given that it also came up in GEOPRIV. http://www.ietf.org/mail-archive/web/geopriv/current/msg08451.html When the topic of suboptions first came up, it was because I proposed them as an alternative to a complicated internal option structure with lots of special code required in the server to implement. But given that only one Location URI option is allowed, there's no need for suboptions. > I'm not sure the additional text is necessary given that there is an entire paragraph explaining considerations for servers in setting the Valid-For value. Furthermore, I don't see how "potential loss of service" is possible. We're talking about a URI with an expiration. When it expires, location recipients will no longer have access to the client's location, but it otherwise doesn't affect recipients' ability to use any "service" whatsoever. You're right—don't know how I missed that. >> Section 3.2 suggests that options shouldn't contain certain potentially harmful values, but this is a toothless restriction, since an attacker can simply ignore it. In order for it to be effective, Section 3.2 should insist that DHCP clients reject forbidden URI formats. Of course, this too is somewhat toothless, since any list of forbidden URI formats will necessarily fail to mention any future potentially harmful URIs that could arise. It would be better to list which URIs _are_ permitted, and require the client to reject any URI that is not permitted. The document is already set up to do this, but(Continue reading)
The authors of this draft believe that their work on it is complete and have asked for a working group last call. The draft is a bit of transition technology to enable allocation of IPv4 addresses for tunnel endpoints on an IPv6-only network using DHCP. It works by relaying DHCPv4 packets over DHCPv6. The DHC working group is agnostic to whether this is the right way to set up tunnels; the question for the DHC working group is whether this is a good DHCP protocol extension. Please review the draft for correctness and indicate whether or not you support advancing it. If you are in favor, please say so. If you aren't, please say so, and (ideally) explain why. We will evaluate consensus sometime on or after June 9. Thanks!
We will evaluate consensus sometime on or after June 9.
_______________________________________________ dhcwg mailing list dhcwg <at> ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
> We will evaluate consensus sometime on or after June 9. => July 9? I support the draft and have two comments: - I implemented it (it is used in Light weight Dual-Stack Lite demos) - if/when it will be adopted it should be fine to define a new DHCPv6 option giving DHCPv4-over-IPv6 agents (i.e., TRA or TSV), something like an array of IPv6 addresses should do the job... Thanks Francis.Dupont <at> fdupont.fr (or fdupont <at> isc.org for the first comment)
RSS Feed77 | |
|---|---|
207 | |
148 | |
120 | |
39 | |
116 | |
146 | |
147 | |
190 | |
157 | |
101 | |
25 | |
21 | |
124 | |
168 | |
80 | |
33 | |
108 | |
60 | |
97 | |
50 | |
46 | |
58 | |
47 | |
91 | |
35 | |
61 | |
9 | |
26 | |
51 | |
42 | |
146 | |
107 | |
155 | |
24 | |
27 | |
41 | |
44 | |
54 | |
232 | |
57 | |
33 | |
137 | |
120 | |
39 | |
24 | |
86 | |
27 | |
27 | |
91 | |
168 | |
60 | |
92 | |
114 | |
75 | |
205 | |
126 | |
123 | |
130 | |
29 | |
37 | |
38 | |
60 | |
63 | |
58 | |
160 | |
281 | |
109 | |
87 | |
149 | |
37 | |
76 | |
41 | |
43 | |
191 | |
146 | |
69 | |
39 | |
110 | |
92 | |
71 | |
95 | |
72 | |
148 | |
44 | |
33 | |
152 | |
123 | |
48 | |
67 | |
140 | |
130 | |
97 | |
46 | |
138 | |
96 | |
199 | |
36 | |
98 | |
111 | |
90 | |
74 | |
81 | |
76 | |
70 | |
200 | |
99 | |
57 | |
41 | |
161 | |
157 | |
192 | |
103 | |
67 | |
152 | |
239 | |
60 | |
50 | |
126 | |
78 | |
62 | |
53 | |
81 | |
206 | |
90 | |
46 | |
63 | |
109 | |
56 | |
54 | |
72 | |
66 | |
200 | |
68 | |
1 |
