headers
Ted Lemon | 2 Sep 2010 18:57
Gravatar

Re: Questions about layer two relay agents in dhcpv4...

On Aug 27, 2010, at 6:43 AM, Bharat Joshi wrote:
>      If you guys can provide feedback on whether we should target L2 RA for standard track or Informational RFC.
If everyone is fine with it being a standard track RFC, we will need to make few changes. If it can only be an
informational one, we will add sufficient amount of text to fix the problem pointed out by Ted or remove
that point all together.

Sorry, got lost in the weeds.   I would rather have the l2ra draft be standards-track than put all the l2ra
standard stuff into the relay encapsulation draft.   I am working on a new version of the relay
encapsulation draft, which will contain the l2ra text I want--I'd suggest that when I publish it, you
steal all the text that specifies how l2ras have to work that isn't specific to encapsulation (I can work
with you on this), and spin a new version of the l2ra draft with that text in it and then we can examine the l2ra
draft and see what to take out of it.   I suggest doing it this way only because I want to have the spec clear
before we start chopping it up... :')
Permalink | Reply | 0 comments |
headers
Ted Lemon | 2 Sep 2010 19:01

Re: [HOKEY] Fw: draft-ietf-hokey-ldn-discovery WGLC ends

On Aug 24, 2010, at 6:22 AM, Glen Zorn wrote:
Looks fine to me, but the question is one of timing: as you know, we are past WGLC on this doc, so I’m wondering how close your draft is to publication as an RFC (my guess is that it’s a ways out).  The problem is that any reference to your draft would need to be normative, which would essentially stop all progress on this draft.

I don't want to delay your draft, and at the same time I don't want to have new non-option DHCP protocol specification in an option draft.   I think the right thing to do would be to add you (or one of the other authors of this draft) as an author on the relay-supplied-options draft and let you be the driving force behind it.   That way you don't have to feel like you have to depend on me to make forward progress, but we get both drafts instead of just one.   I think the rso draft is pretty close to done--the only delay on it is that I originally wrote it to benefit a different protocol spec, and the author of that spec hasn't communicated with me since the Anaheim IETF, so I had it on the back burner.

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 3 comments |
headers
jouni korhonen | 2 Sep 2010 20:32
Picon

New Version Notification for draft-korhonen-dhc-pd-exclude-01 was Re: Relaxing text in RFC3633 [recap]

Folks,

We have updated draft-korhonen-dhc-pd-exclude. It should now reflect the longish discussion we had
since IETF78. The prefix exclusion solution has also been greatly simplified since version -00.

Comments are solicited.

- Jouni

On Aug 20, 2010, at 12:46 AM, <teemu.savolainen <at> nokia.com> <teemu.savolainen <at> nokia.com> wrote:

> Hi,
> 
> I wish to ensure people are clear that the problem we have in 3GPP EPC is not fixed by allowing RR to assign a
prefix to its uplink, because a prefix must be allocated to RR's uplink even before RR is requesting any
(i.e. a /64 is allocated with SLAAC before RR asks for prefix delegation).
> 
> I agree fix for that should be on separate specification (as we propose).
> 
> Best regards,
> 
> Teemu
> 
>> -----Original Message-----
>> From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf
>> Of ext Ralph Droms
>> Sent: 19. elokuuta 2010 01:22
>> To: Ted Lemon
>> Cc: DHC Group Working; alexandru.petrescu <at> gmail.com
>> Subject: Re: [dhcwg] Relaxing text in RFC3633 [recap]
>> 
>> Ted - seems to me that there may well be deployment scenarios in which
>> the RR decides on the RR-DR prefix.  It's a policy decision, which
>> shouldn't be in an update to RFC 3633.
>> 
>> BTW, filing an erratum is only the first step of the process.  The
>> erratum is reviewed by the Appropriate Experts before it is approved
>> for publication.
>> 
>> - Ralph
>> 
>> On Aug 18, 2010, at 5:19 PM 8/18/10, Ted Lemon wrote:
>> 
>>> On Aug 18, 2010, at 3:35 PM, Ralph Droms wrote:
>>>> In any event, in my opinion it is out of scope for RFC 3633 to make
>> a policy statement about which of the DR and RR is responsible for the
>> prefix assigned to the RR-DR link.
>>> 
>>> That may or may not be so, but my point is that it simply doesn't
>> make sense for the RR to offer a prefix it received from the DR on the
>> upstream link.   Isn't that what that text was intended to prevent?
>>> 
>> 
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 1 comment |
headers
RFC Errata System | 3 Sep 2010 20:51
Favicon

[Technical Errata Reported] RFC3315 (2509)


The following errata report has been submitted for RFC3315,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".

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

--------------------------------------
Type: Technical
Reported by: Suresh Krishnan <suresh.krishnan <at> ericsson.com>

Section: 22.7

Original Text
-------------
A server MAY include an Option Request option in a Reconfigure option to indicate which options the client
should request from the server.

Corrected Text
--------------
A server MAY include an Option Request option in a Reconfigure message to indicate which options the client
should request from the server.

Notes
-----
There is no such thing as a "Reconfigure option". I believe that the intent was to refer to the Reconfigure
message instead.

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. 

--------------------------------------
RFC3315 (draft-ietf-dhc-dhcpv6-28)
--------------------------------------
Title               : Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Publication Date    : July 2003
Author(s)           : R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney
Category            : PROPOSED STANDARD
Source              : Dynamic Host Configuration
Area                : Internet
Stream              : IETF
Verifying Party     : IESG
Permalink | Reply | 1 comment |
headers
Bernie Volz | 4 Sep 2010 16:27

Re: [Technical Errata Reported] RFC3315 (2509)

This change is fine as far as I'm concerned.

- Bernie

On Sep 3, 2010, at 2:51 PM, RFC Errata System <rfc-editor <at> rfc-editor.org> wrote:

> 
> The following errata report has been submitted for RFC3315,
> "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3315&eid=2509
> 
> --------------------------------------
> Type: Technical
> Reported by: Suresh Krishnan <suresh.krishnan <at> ericsson.com>
> 
> Section: 22.7
> 
> Original Text
> -------------
> A server MAY include an Option Request option in a Reconfigure option to indicate which options the client
should request from the server.
> 
> Corrected Text
> --------------
> A server MAY include an Option Request option in a Reconfigure message to indicate which options the
client should request from the server.
> 
> Notes
> -----
> There is no such thing as a "Reconfigure option". I believe that the intent was to refer to the Reconfigure
message instead.
> 
> 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. 
> 
> --------------------------------------
> RFC3315 (draft-ietf-dhc-dhcpv6-28)
> --------------------------------------
> Title               : Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
> Publication Date    : July 2003
> Author(s)           : R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney
> Category            : PROPOSED STANDARD
> Source              : Dynamic Host Configuration
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
Permalink | Reply | 0 comments |
headers
Shoichi Sakane | 6 Sep 2010 05:23
Favicon

Re: [Ietf-krb-wg] WG LastCall: draft-sakane-dhc-dhcpv6-kdc-option-08

Hi Ted,

On 09/02/10 23:47, Ted Lemon wrote:
>> On Sep 2, 2010, at 4:05 AM, Shoichi Sakane wrote:
>>> On 09/02/10 12:06, Ted Lemon wrote:
>>> And in the long run it's harmful, since if we add IPv4 options
>>> to the DHCPv6 protocol now, we are stuck with them forever.
>> Well, could you explain bit precisely why it's harmful.  I would
>> like to convince myself.
>
> More complexity in the protocol. More choices as to where a
> particular piece of configuration information comes from.
> More potential for ambiguity. More to get wrong, basically.

The first and the third are about a documenting issue.
In terms of the operator and the implementation of the server,
the second one is enough for me to understand the reason.

In terms of the client implementation and the transition phase,
if DHCPv6 protocol was able to provide configuration about IPv4 address,
a client would not need to have the DHCPv4 protocol and the parser.
It could save the resouce of a client.  However, in the long run,
I agree with you.  The waste parser routine is harmful.

Thanks, I am convinced.

Shoichi Sakane

P.S.
I apologize that I accidentally removed the dhcwg ML address.
Discussion was kept in the krb-wg ML.  Please find them if interested.
Permalink | Reply | 2 comments |
headers
Bernie Volz (volz | 6 Sep 2010 16:14
Picon
Favicon

Re: I-D Action:draft-ietf-dhc-80211-option-01.txt

I believe you want to define this option for both DHCPv4 and DHCPv6?

But ...

1. The figure in section 2 is only valid for the DHCPv6 option. DHCPv4
options have a 1-octet (8-bit) option-code and option-length field, not
2-octet (16-bit) values. You should define each separately.

2. The option number cannot be shared between DHCPv4 and DHCPv6 - each
need their own option number.

The text in section 2 also should be clear that clients should request
this option in the (DHCPv4) Parameter Request List or (DHCPv6) Option
Request Option. This is the normal way the server knows which options to
return to the client (provided of course the option is configured in the
server).

Finally, some more about how this is supposed to work needs to be
documented. If the client is able to perform DHCP (which are IP/UDP
based communication) how does this SSID (i.e., hasn't the client already
found the SSID given that it is communicating)? Is the client expected
to change SSID once DHCP[v4/v6] is done and this value is provided? Is
this value being provided over a different interface for use with a
wireless interface? Or?

Perhaps those with detailed knowledge of 802.11 know how this
information is supposed to be used, but ...

Also, we've been using 802.11 networks for many years now without this.
So, why is this now needed?

Seems like you're also missing some basic references (such as to RFC
3315)?

- Bernie

-----Original Message-----
From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf
Of Krzysztof Grochla
Sent: Sunday, August 29, 2010 3:25 PM
To: Internet-Drafts <at> ietf.org; i-d-announce <at> ietf.org
Cc: dhcwg <at> ietf.org
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-80211-option-01.txt

Dear DHC WG,

By mistake I've submitted this draft as a working group document, thus
it has been withdrawn. My intention was to submit this as an individual
draft ask the group for a review. I'm sorry for this misnaming. I've
corrected this now and submitted the individual draft as
http://tools.ietf.org/html/draft-grochla-80211-dhcp-option-00. 

I would like kindly ask you to review the above mentioned draft to
answer if it shall be further proceeded. It is a fairly simple
specification of options for basic WiFi AP configuration (the channel
and SSID). This can be used for quick and simple configuration of these
parameters using DHCP or by autoconfiguration schemes for WiFi networks
based on DHCP. Do you think there is room for such standardization?

Thanks,
Krzysztof

> 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           : IEEE 802.11 parameters DHCP Option
>	Author(s)       : K. Grochla
>	Filename        : draft-ietf-dhc-80211-option-01.txt
>	Pages           : 5
>	Date            : 2010-08-27
>
> The wireless access points and other devices requires configuration of
parameters such as channel, ESSID. This document describes the DHCP
options to be used to configure these parameters.

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-80211-option-01.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 0 comments |
headers
Mark Townsley | 9 Sep 2010 07:01
Picon
Favicon

Re: Is tunnelling DHCP multicast messages in 6rd unicast tunnel to BR acceptable for DHCP redundancy?//re: [Softwires] About draft-guo-softwire-6rd-ipv6-config-00

On 8/16/10 3:29 AM, Xu Xiaohu wrote:
> 
> 
>> -----邮件原件-----
>> 发件人: Ted Lemon [mailto:Ted.Lemon <at> nominum.com]
>> 发送时间: 2010年8月15日 1:15
>> 收件人: Xu Xiaohu
>> 抄送: 'Ole Troan'; softwires <at> ietf.org; dhcwg <at> ietf.org
>> 主题: Re: [dhcwg] Is tunnelling DHCP multicast messages in 6rd unicast
> tunnel
>> to BR acceptable for DHCP redundancy?//re: [Softwires] About
>> draft-guo-softwire-6rd-ipv6-config-00
>>
>> On Aug 8, 2010, at 11:59 PM, Xu Xiaohu wrote:
>>> In addition, in case that the DHCP
>>> server/relay on a given BR is unavailable due to some reason (e.g., no
>>> available address in the pool) but the other functions of it (e.g., the
>>> anycast route for it) are still available, once the DHCP message is
> tunneled
>>> to that BR, the DHCP service is unavailable any more. That's to say,
> it's
>>> hard to achieve the high availability for DHCP servers/relay agents
> since
>>> the DHCP information-request can not be relayed to other DHCP
>>> servers/relays.
>>
>> I don't see the problem here.   If you want redundancy, you should
> configure
>> each BR to relay to more than one DHCP server.   This would be the default
> anyway,
>> according to RFC3315 section 20, which requires the relay to multicast if
> not
>> otherwise configured.
> 
> However, the BR itself (no matter as a relay agent or a DHCP server) is a
> single point of failure, especially in the case where the DHCP service on
> the BR is unavailable while the route for it (anycast address) is still OK. 

Why would you ever deploy 6rd with one BR? We're talking about stateless
DHCP operation here, so *all* the BRs in the SP network could run this
(indeed, all would have to if addressed via the anycast address that 6rd
uses to reach the BRs since you don't know in advance which one you
would reach). As long as all participating BRs have the server or relay
function, I see no single point of failure problem.

- Mark
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 1 comment |
headers
Ted Lemon | 10 Sep 2010 22:03

Re: [Ietf-krb-wg] WG LastCall: draft-sakane-dhc-dhcpv6-kdc-option-08

The new draft looks fine.   I assume you are only sending on IP address for each KDC because you don't think it's
useful to send more than one, not because you feel constrained by the DHCP protocol to only send one.
Permalink | Reply | 1 comment |
headers
Alexandru Petrescu | 10 Sep 2010 23:41
Picon

Default Route configured by DHCPv6?

Hello DHC,

I am not updated with latest advancements, sorry.   The discussion comes
from the draft-ietf-mext-nemo-pd-06 LC of IESG recently.

I need a default route configured automatically in the Mobile Router
connected at home.

Is it possible that the DHCPv6-PD specification to allow for the
creation of a default route on the Requesting Router? (in addition to
configuring a Prefix on it).

A Mobile Router (Mobile IPv6, NEMOv6) connected on home link acquires a
Prefix (Mobile Network Prefix) from a DHCPv6 Server using the DHCPv6-PD,
a little bit like draft-ietf-mext-nemo-pd-06.  This is very encouraging
because it automates almost everything in the bootstrapping of a Mobile
Router:  it acquires an address too (the Home Address), the resolver,
etc.  However it does not acquire a default route w/o which nothing
leaves from the moving network.

This being a Router it does not self-configure a default route from
SLAAC either.

Is this a software problem only?  (i.e. DHCPv6-PD does allow this
creation of default route, yet software doesnt yet implement, or so).

Does DHCPv6 and DHCPv6-PD text forbid the creation of this default route
on a Requesting Router? (as opposed to DHCPv4 which does create a
default route on a Client).

Is there in DHCPv6-PD an assumption that the default route on the
Requesting Router is always the Delegating Router? (and not the Relay,
for example).

Is there already a draft in DHC which proposes to create this default
route with DHCPv6?

Would there be any opposition if I wrote a draft about DHCPv6 setting
the default route on the Client (as DHCPv4 does) in DHC group?

Comments appreciated.

Alex
Permalink | Reply | 16 comments |

Gmane