From shawngespan@gmail.com Thu Mar 1 05:05:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC5D21F87DA for ; Thu, 1 Mar 2012 05:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2e4zxHXevBt for ; Thu, 1 Mar 2012 05:05:26 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45C0221F8835 for ; Thu, 1 Mar 2012 05:05:25 -0800 (PST) Received: by bkuw5 with SMTP id w5so548626bku.31 for ; Thu, 01 Mar 2012 05:05:24 -0800 (PST) Received-SPF: pass (google.com: domain of shawngespan@gmail.com designates 10.204.157.138 as permitted sender) client-ip=10.204.157.138; Authentication-Results: mr.google.com; spf=pass (google.com: domain of shawngespan@gmail.com designates 10.204.157.138 as permitted sender) smtp.mail=shawngespan@gmail.com; dkim=pass header.i=shawngespan@gmail.com Received: from mr.google.com ([10.204.157.138]) by 10.204.157.138 with SMTP id b10mr2566505bkx.75.1330607124462 (num_hops = 1); Thu, 01 Mar 2012 05:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PaU+4XkflbThzLwTnfMBxxt1651jO5LyEfHXIPR9+IE=; b=Qb1llspDBtOd76FsLtzGlMwB3r1md8rt9TDNlVCr0Bxq9g3/qx5KN3IDm1fdmtGGUn oZaHYGlV9YOcS5Z13pJEID3D6pNT0kDpSovpNE3No1oCsJ3BQkF2R13jslxWzHkB1r/s 1k3+zYqdN7DKkMoUp3Z+Y60o5SmqNCR4TCXj8= MIME-Version: 1.0 Received: by 10.204.157.138 with SMTP id b10mr2048387bkx.75.1330607124319; Thu, 01 Mar 2012 05:05:24 -0800 (PST) Received: by 10.204.65.200 with HTTP; Thu, 1 Mar 2012 05:05:24 -0800 (PST) In-Reply-To: References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> Date: Thu, 1 Mar 2012 21:05:24 +0800 Message-ID: From: Huan Huan To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=0015175cd0e0fb0d3104ba2e1c7a Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 13:05:31 -0000 --0015175cd0e0fb0d3104ba2e1c7a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, I really want to know the end of this issue? Should we need to modify RFC3633 or we need a new draft? Regards, Huan 2012/2/16 Bernie Volz (volz) > > I asked Ole about this at V6 World Congress last week, and he > mentioned that it wasn't in RFC 3633 because Confirm is for detecting > on-link confirmation. It's possible I misunderstood him, if so he can > feel free to jump in.**** > > ** ** > > Any responding servers will indicate whether those**** > > addresses are appropriate for the link to which the client is**** > > attached with the status in the Reply message it returns to the**** > > client.**** > > ** ** > > =85**** > > ** ** > > NotOnLink 4 The prefix for the address is not appropriate for***= * > > the link to which the client is attached.**** > > ** ** > > I disagree as the RFC 3315 text never says =93on-link=94 in the strict se= nse > of what =93on-link=94 means for IPv6. It says =93appropriate for the link= =94. The > status code is =93NotOnLink=94 but that is something that is definitive i= n the > case when a delegate prefix is not =91appropriate=92 for the link. I beli= eve > Ralph was purposely careful in the language used in RFC 3315 that we didn= =92t > imply that an address was =93on-link=94 in the sense of the L bit for ND.= **** > > ** ** > > I don=92t remember the timing of the documents and work on RFC 3633 might > have started before RFC 3315 was finalized and perhaps an earlier 3315 > draft had some different terminology which was more directly tied to > =93on-link=94. (Given that the RFC publication dates are only 6 months ap= art, I > suspect they were worked on in parallel. While the IETF process was faste= r > back then, it was never that fast.)**** > > ** ** > > > Is a DHCP Client not following RFC 3315 if they don't transmit > a DHCP Confirm message? **** > > ** ** > > In any situation when a client may have moved to a new link, the**** > > client MUST initiate a Confirm/Reply message exchange. **** > > ** ** > > Thus, a strict read of RFC 3315 says it is required (MUST =96 not SHOULD)= .** > ** > > ** ** > > Perhaps the above are items for -bis documents if they are ever done. Or, > a new draft might want to propose a reconsidering of these issues?**** > > ** ** > > **- **Bernie**** > > ** ** > > *From:* Timothy Winters [mailto:twinters@iol.unh.edu] > *Sent:* Wednesday, February 15, 2012 11:53 PM > *To:* Bernie Volz (volz) > *Cc:* Huan Huan; dhcwg@ietf.org > > *Subject:* Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm**** > > ** ** > > Hi Bernie,**** > > I asked Ole about this at V6 World Congress last week, and he > mentioned that it wasn't in RFC 3633 because Confirm is for detecting > on-link confirmation. It's possible I misunderstood him, if so he can > feel free to jump in.**** > > ** ** > > As you point out RFC 3315 doesn't prevent an implementation > from transmitting a Renew message when this happens. So they are within > the specification for transmitting the Renew message. The missing piece = is > that we have DHCP clients, in this case CE Routers, that don't transmit > Confirm messages. RFC 3315 states a Confirm message should happen when a > device may have moved to another link, so unplugging the physical link > should cause a DHCP Confirm message when plugged back in. **** > > ** ** > > Is a DHCP Client not following RFC 3315 if they don't > transmit a DHCP Confirm message? **** > > ** ** > > Regards,**** > > Tim**** > > ** ** > > On Feb 15, 2012, at 10:29 PM, Bernie Volz (volz) wrote:**** > > > > **** > > I don=92t really see what=92s wrong with EITHER a REBIND or CONFIRM (or e= ven > both, one for IA_PD and one for address). Not really sure why RFC 3633 > didn=92t permit a Confirm.**** > > **** > > However, if one does a strict read of the standards, the two (Confirm for > address, Renew for PD) is what a client SHOULD do.**** > > **** > > But, there=92s no reason a prefix can=92t be confirmed just as easily as = an > address.**** > > **** > > Perhaps Ole had a reason for this in RFC 3633, but alas it is not > documented (at least that I could see).**** > > **** > > And, a Rebind (for an address) at any time isn=92t really =93wrong=94.***= * > > **** > > For a compliance test, you are probably forced to follow the standards as > that is the only thing that you can assure (a server may be strict in > following RFC 3633 and consider a Confirm with prefixes =93wrong=94). (Ci= sco > Network Registrar will deal with all of the possibilities.)**** > > - Bernie**** > > **** > > *From:* dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] *On Behalf > Of *Huan Huan > *Sent:* Wednesday, February 15, 2012 8:56 PM > *To:* Timothy Winters > *Cc:* dhcwg@ietf.org > *Subject:* Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm**** > > **** > > I don't think so.**** > > **** > > 2012/2/15 Timothy Winters **** > > Hi Huan,**** > > Is it ok to transmit just a Renew message containing both the IA_NA > and IA_PD when the link goes down?**** > > **** > > Regards,**** > > Tim**** > > > > On Feb 14, 2012, at 8:12 PM, Huan Huan wrote:**** > > Hi Tim,**** > > **** > > I think CE Router may transmit Confirm msg containing the assigned IA_NA > and Renew msg containing the assigned IA_PD separately.**** > > **** > > BR,**** > > Huan **** > > 2012/2/15 **** > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/dhcwg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send dhcwg mailing list submissions to > dhcwg@ietf.org > > 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 > dhcwg-request@ietf.org > > You can reach the person managing the list at > dhcwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dhcwg digest..." > > > Today's Topics: > > 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > (internet-drafts@ietf.org) > 2. DHCP Renew vs Confirm (Timothy Winters) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Feb 2012 02:40:41 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset=3D"utf-8" > > > 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-04.txt > Pages : 12 > Date : 2012-02-14 > > 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 on the initial > DHCP ACK that is used for subsequent validation of a FORCERENEW > message. This document updates RFC 3203. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.tx= t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt > > > > ------------------------------ > > Message: 2 > Date: Tue, 14 Feb 2012 08:43:50 -0500 > From: Timothy Winters > To: dhcwg@ietf.org > Subject: [dhcwg] DHCP Renew vs Confirm > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii > > Hello, > While testing some CE Router implementations we have noticed a > interesting behavior that is within the specifications but not clearly > documented. I wanted to get the working group thoughts on this. > > Currently when a CE Router acting as a DHCP client, assigned both > IA_NA and IA_PD, is unplugged from the network. When reattached to the > link the DHCP client transmits a DHCP Renew containing both the IA_NA and > the IA_PD. > > 3315 Section 18.1.2 says that when link goes down a DHCP client > implementation should transmit a DHCP Confirm message containing the > assigned IA_NA. > > 3633 Section 12.1 doesn't allow the use of the Confirm message. I= t > states that DHCP Renew message, containing the assigned IA_PD, should be > used when the link goes down. > > According to the specifications a DHCP client should retransmit > DHCP Confirm and DHCP Renew when link goes up. The behavior we are seei= ng > is the DHCP client transmits a DHCP renew containing both the IA_NA and > IA_PD. > > This behavior isn't causing interoperability issues as all the > servers we have tried still respond properly to the DHCP Renew messages. > > Is it ok when a DHCP client loses link for it to transmit one DHCP > Renew message? > > Regards, > Tim > UNH-IOL > > > > ------------------------------ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > End of dhcwg Digest, Vol 94, Issue 13 > ***************************************** > > > > **** > > **** > > -- > Huan Huan**** > > > > **** > > **** > > -- > Huan Huan**** > > ** ** > --=20 Huan Huan --0015175cd0e0fb0d3104ba2e1c7a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all,

I really want to know the end of this issue? Sho= uld we need to modify RFC3633 or we need a new draft?

<= div>Regards,

Huan

2012/2/16 Bernie Volz (volz) <volz@cisco.com>
<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">

>=A0=A0=A0=A0=A0=A0= =A0=A0=A0 I asked Ole about this at V6 World Congress last week, and= he mentioned that it wasn't in RFC 3633 because Confirm is for detecti= ng on-link confirmation. =A0 It's possible I misunderstood him, if so h= e can feel free to jump in.

=A0<= /p>

=A0=A0 Any respon= ding servers will indicate whether those

=A0=A0 addresses are appropr= iate for the link to which the client is

=A0=A0= attached with the status in the Reply message it returns to the<= /u>

=A0=A0 client.=

=A0<= /p>

=85

=A0<= /p>

=A0=A0 NotOnLink=A0=A0=A0= =A0=A0=A0 4 The prefix for the address is not appropriate for=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 the link to which the client is attached.

=A0<= /p>

I disagree as the RFC = 3315 text never says =93on-link=94 in the strict sense of what =93on-link= =94 means for IPv6. It says =93appropriate for the link=94. The status code= is =93NotOnLink=94 but that is something that is definitive in the case wh= en a delegate prefix is not =91appropriate=92 for the link. I believe Ralph= was purposely careful in the language used in RFC 3315 that we didn=92t im= ply that an address was =93on-link=94 in the sense of the L bit for ND.<= /u>

=A0<= /p>

I don=92t remember the= timing of the documents and work on RFC 3633 might have started before RFC= 3315 was finalized and perhaps an earlier 3315 draft had some different te= rminology which was more directly tied to =93on-link=94. (Given that the RF= C publication dates are only 6 months apart, I suspect they were worked on = in parallel. While the IETF process was faster back then, it was never that= fast.)

= =A0

>=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Is a DHCP Client not following RFC 3315 if they don't tra= nsmit a DHCP Confirm message?=A0

=A0

=

=A0=A0 In any situatio= n when a client may have moved to a new link, the

=A0=A0 client MUST initiate a Confirm/Reply message exchan= ge.=A0

=A0<= /p>

Thus, a strict read of= RFC 3315 says it is required (MUST =96 not SHOULD).

=A0<= /p>

Perhaps the above are = items for -bis documents if they are ever done. Or, a new draft might want = to propose a reconsidering of these issues?

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bernie

=A0<= /p>

From: Timothy = Winters [mailto:t= winters@iol.unh.edu]
Sent: Wednesday, February 15, 2012 11:53 PM
To: Bernie Vol= z (volz)
Cc: Huan Huan; dhcwg@ietf.org

=
Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm

=A0

Hi Bernie,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = I asked Ole about this at V6 World Congress last week, and he mentioned tha= t it wasn't in RFC 3633 because Confirm is for detecting on-link confir= mation. =A0 It's possible I misunderstood him, if so he can feel free t= o jump in.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 As you point = out=A0RFC 3315 doesn't prevent an implementation from transmitting a Re= new message when this happens. =A0 So they are within the specification for= transmitting the Renew message. =A0The missing piece is that we have DHCP = clients, in this case CE Routers, that don't transmit Confirm messages.= RFC 3315 states a Confirm message should happen when a device may have mov= ed to another link, so unplugging the physical link should cause a DHCP Con= firm message when plugged back in. =A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Is a DHCP Cli= ent not following RFC 3315 if they don't transmit a DHCP Confirm messag= e?=A0

=A0

Regards,

Tim<= /u>

=A0

<= div>

On Feb 15, 2012, at 10:29 PM, Bernie Volz (volz) wrote:



I don=92t really see what=92s wrong w= ith EITHER a REBIND or CONFIRM (or even both, one for IA_PD and one for add= ress). Not really sure why RFC 3633 didn=92t permit a Confirm.

=A0<= /u>

= However, if one does a strict read of the standards, the two (Confirm for a= ddress, Renew for PD) is what a =A0client SHOULD do.

=A0<= /u>

= But, there=92s no reason a prefix can=92t be confirmed just as easily as an= address.

=A0<= /u>

= Perhaps Ole had a reason for this in RFC 3633, but alas it is not documente= d (at least that I could see).

=A0<= /u>

= And, a Rebind (for an address) at any time isn=92t really =93wrong=94.

=A0<= /u>

= For a compliance test, you are probably forced to follow the standards as t= hat is the only thing that you can assure (a server may be strict in follow= ing RFC 3633 and consider a Confirm with prefixes =93wrong=94). (Cisco Netw= ork Registrar will deal with all of the possibilities.)

-=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0Bern= ie

=A0<= /u>

From:= =A0dhcwg-bounces@ietf.org [mailto:dhcwg-boun= ces@ietf.org]=A0On Behalf Of=A0Huan Hu= an
Sent:=A0Wednesday, February 15, 2012 8:56 PM
To:<= /b>=A0Timothy Winters
Cc:=A0dhcwg@ietf.org
Subject:<= /b>=A0Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm

=A0

I don't think so.

=A0

2012/2/15 Timothy Winters <twinters@iol.unh.edu>

Hi Huan,

=A0 =A0 =A0 Is it ok to transmit ju= st a Renew message containing both the IA_NA and IA_PD when the link goes d= own?

=A0

Regards,

<= div>

Tim



On Feb 14, 2012, at 8:12 PM, Huan Huan <shawngespan@gmail.com> wrote:<= /u>

Hi Tim,

=

=A0

I think CE Router may transmit Confirm msg=A0containing = the assigned IA_NA and Renew msg=A0containing the assigned IA_PD separately= .

=A0

BR,

Huan=A0

If you have received this digest without all the individual message attachments you will need to update your digest options in your list
sub= scription. =A0To do so, go to

https://www.ietf.org/mailman/listinfo/d= hcwg

Click the 'Unsubscribe or edit options' button, log in, and set= "Get
MIME or Plain Text Digests?" to MIME. =A0You can set thi= s option
globally for all the list digests you receive at this point.


Send dhcwg mailing list submissions to
=A0 =A0 =A0 =A0dhcwg@ietf.org

To = subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0htt= ps://www.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
=A0= =A0 =A0 =A0dhc= wg-request@ietf.org

You can reach the person managing the list a= t
=A0 =A0 =A0 =A0dhcwg-owner@ietf.org

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


Today's Top= ics:

=A0 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
=A0 =A0 =A0(i= nternet-drafts@ietf.org)
=A0 2. DHCP Renew vs Confirm (Timothy Winte= rs)


------------------------------------------------------------= ----------

Message: 1
Date: Tue, 14 Feb 2012 02:40:41 -0800
From:=A0internet= -drafts@ietf.org
To:=A0i-d-announce@ietf.org
Cc:=A0dhcw= g@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-no= nce-04.txt
Message-ID: <20120214104041.23040.30559.idtr= acker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"


A New Inte= rnet-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.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Forcerenew Nonce Authenticat= ion
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : David Miles
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wojciech Dec
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0James Bristow
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0Roberta Maglione
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dhc-forcerenew-nonce-04= .txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0Dat= e =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-14

=A0 Dynamic Host Configuration= Protocol (DHCP) FORCERENEW allows for the
=A0 reconfiguration of a sing= le host by forcing the DHCP client into a
=A0 Renew state on a trigger from the DHCP server. =A0In Forcerenew Nonce=A0 Authentication the server sends a nonce to the client on the initial<= br>=A0 DHCP ACK that is used for subsequent validation of a FORCERENEW
= =A0 message. =A0This document updates RFC 3203.


A URL for this Internet-Draft is:
= http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt<= /a>

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-f= orcerenew-nonce-04.txt



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

Message: 2
Date: Tue, = 14 Feb 2012 08:43:50 -0500
From: Timothy Winters <twinters@iol.unh.edu>
To:<= span>=A0dhcwg@ie= tf.org
Subject: [dhcwg] DHCP Renew vs Confirm
Message-ID: <C0CA95= B6-1743-4D37-9BCC-D104453EBF9A@iol.unh.edu>
Content-Type: text/pl= ain; charset=3Dus-ascii

Hello,
=A0 =A0 =A0 =A0While testing some CE Router implementations w= e have noticed a interesting behavior that is within the specifications but= not clearly documented. =A0I wanted to get the working group thoughts on t= his.

=A0 =A0 =A0 =A0Currently when a CE Router acting as a DHCP client, assi= gned both IA_NA and IA_PD, is unplugged from the network. =A0When reattache= d to the link the DHCP client transmits a DHCP Renew containing both the IA= _NA and the IA_PD.

=A0 =A0 =A0 =A03315 Section 18.1.2 says that when link goes down a DHCP= client implementation should transmit a DHCP Confirm message containing th= e assigned IA_NA.

=A0 =A0 =A0 =A03633 Section 12.1 doesn't allow= the use of the Confirm message. =A0It states that DHCP Renew message, cont= aining the assigned IA_PD, should be used when the link goes down.

=A0 =A0 =A0 =A0According to the specifications a DHCP client should ret= ransmit DHCP Confirm and DHCP Renew when link goes up. =A0 The behavior we = are seeing is the DHCP client transmits a DHCP renew containing both the IA= _NA and IA_PD.

=A0 =A0 =A0 =A0This behavior isn't causing interoperability issues = as all the servers we have tried still respond properly to the DHCP Renew m= essages.

=A0 =A0 =A0 =A0Is it ok when a DHCP client loses link for i= t to transmit one DHCP Renew message?

Regards,
Tim
UNH-IOL



-----------------------------= -

_______________________________________________
dhcwg mailing l= ist
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


End of dhcwg Dige= st, Vol 94, Issue 13
*************************************=



=A0

--=A0
Huan Huan=



=A0

--= =A0
Huan Huan

<= u>=A0



--
Huan Huan
--0015175cd0e0fb0d3104ba2e1c7a-- From Ted.Lemon@nominum.com Thu Mar 1 06:05:20 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8012921E85D1 for ; Thu, 1 Mar 2012 06:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtw2+ibon9gp for ; Thu, 1 Mar 2012 06:05:19 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 492EE21E85D4 for ; Thu, 1 Mar 2012 06:04:43 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT0+B+sZOzfLpTjdzjsX4qJGSZ3o1kbIs@postini.com; Thu, 01 Mar 2012 06:04:43 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 72D4D1B8346 for ; Thu, 1 Mar 2012 06:04:42 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6685819005D; Thu, 1 Mar 2012 06:04:42 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 1 Mar 2012 06:04:42 -0800 From: Ted Lemon To: Huan Huan Thread-Topic: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Thread-Index: AQHM637zaQSetMIgNES1IZjReImPDpY9ruaAgAGcaYCAABpFAIAAF1eAgAAFrICAFoR1AIAAEI8A Date: Thu, 1 Mar 2012 14:04:41 +0000 Message-ID: <4B5DAD0F-2B92-4D38-BD62-A8E3515A50C4@nominum.com> References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_4B5DAD0F2B924D38BD62A8E3515A50C4nominumcom_" MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:05:20 -0000 --_000_4B5DAD0F2B924D38BD62A8E3515A50C4nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 1, 2012, at 8:05 AM, Huan Huan > wrote: I really want to know the end of this issue? Should we need to modify RFC36= 33 or we need a new draft? Do we know what a new draft would say? --_000_4B5DAD0F2B924D38BD62A8E3515A50C4nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 1, 2012, at 8:05 AM, Huan Huan <shawngespan@gmail.com> wrote:
I really want to know the end of this issue? Should we need to modify RFC36= 33 or we need a new draft?

Do we know what a new draft would say?


--_000_4B5DAD0F2B924D38BD62A8E3515A50C4nominumcom_-- From acooper@cdt.org Thu Mar 1 10:52:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A137421E81C2 for ; Thu, 1 Mar 2012 10:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK1ltQrpqvK6 for ; Thu, 1 Mar 2012 10:52:43 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 23F7321E8080 for ; Thu, 1 Mar 2012 10:52:43 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 1 Mar 2012 13:52:39 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Alissa Cooper In-Reply-To: <4EE116DA.7000901@nostrum.com> Date: Thu, 1 Mar 2012 13:52:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> <201112061938.pB6Jc3pD028634@mtv-core-3.cisco.com> <34043C82-5190-475B-8765-70B9C16FF4D7@nominum.com> <201112070104.pB71408l026419@mtv-core-2.cisco.com> <4EDFDB1C.3040102@nostrum.com> <4EE116DA.7000901@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" , "James M. Polk" , Ted Lemon , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:52:44 -0000 Picking this back up again in the hopes of achieving a resolution... I think we're close to consensus on the relationship (or lack thereof, I = guess), between the lifetime of a location URI and DHCP refresh = mechanics. I suggest the following edit to Section 2.3 to clarify this: =3D=3D=3D OLD: The Valid-For (LuriType=3D2) indicates how long, in seconds, the client is to consider this location URI (LuriType=3D1) valid before performing a refresh of this Option, with a refreshed LuriType=3D2 (Valid-For) value. A client will update its Location = URI either as part of the normal DHCP lease renewal, or through a renewal request sent due to the Valid-For timer reaching the value described in this document. Note that in the second case, the request could ask only for the LocationURI option. The Valid-For (LuriType=3D2) offers no meaningful information without an accompanying Location URI (LuriType=3D1), therefore a Valid-For (LuriType=3D2) MUST NOT be sent without a Location URI (LuriType=3D1). If the Valid-For timer (LuriType=3D2) is received (solicited or unsolicited), it is RECOMMENDED that the client refresh the Location URI when the (Valid-For) counter value reaches approximately the halfway point. For example, if 16000 was the initial value of the Valid-For (LuriType=3D2) value, when 8000 seconds have passed, the Option SHOULD be refreshed. However, if every client on a network were to attempt a refresh at the same time, say if power when out and was brought back up at the same time, there would be an avalanche of location requests or transmissions. This can be avoided by varying the timers between the nodes on the same network. This can be a good reason for not giving out the same Valid-for timer (amount) with each Location URI sent. NEW: The Valid-For (LuriType=3D2) indicates how long, in seconds, the client is to consider this location URI (LuriType=3D1) valid. The = choice of the Valid-For value is a policy decision for the domain = administrator. 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. = Expiration of the Valid-For timeframe does not trigger an automatic = refresh of the location URI or impinge on DHCP mechanics in any other = way -- it merely informs the client of the URI's valid lifetime. The Valid-For (LuriType=3D2) offers no meaningful information without an accompanying Location URI (LuriType=3D1), therefore a Valid-For (LuriType=3D2) MUST NOT be sent without a Location URI (LuriType=3D1). =3D=3D=3D If that satisfies the folks that have been discussing this, I think that = concludes the DHC review of this document. Alissa On Dec 8, 2011, at 2:58 PM, Robert Sparks wrote: > On 12/8/11 11:27 AM, Ted Lemon wrote: >> On Dec 7, 2011, at 4:31 PM, Robert Sparks wrote: >>> If I have it right, the essence of (this part of) your concern is = that a dhcp server can't be constrained >>> to go ask an external process for the information it needs to = respond to a request. That is, it needs >>> to be able to respond to the request with the data it has at the = time the request arrives. The operational >>> model is that the data you have to respond with is the kind of stuff = the server admin would enter as >>> configuration (and it's possible that the admin would need to type = very fast). It would be ok for an external >>> process to be providing new information, but not ok to require the = server to ask that external process for >>> information (or wait on it if information became stale, etc.) >>=20 >> So I've been ruminating about this since my rather terse response = yesterday. I think it's inappropriate for me as an individual or as a = working group chair to be the only one weighing in on this. I have = some pretty strong opinions about what standards should require of DHCP = servers, and I don't really think my opinions are inherently = right=97they're just opinions. >>=20 >> My essential concern about this document is that it seems to be = placing expectations on a DHCP server that I think a typical DHCP server = vendor would not be comfortable with. At the same time, it's also = clear to me that there are DHCP servers out there that could certainly = serve this data, even if they did an in-band query from another server = to fetch it. I know Nominum's DHCP server can do this, and I am pretty = sure CNR can do it as well. >>=20 >> So what I'm saying is that I don't really think it's wrong for a DHCP = server to do this. My concern is that it might not be practical for an = IETF document to effectively _require_ that a DHCP server do this. >>=20 >> That's a fairly weak objection. If this document were to go through = and become a standard, and people didn't want to implement it, they just = wouldn't implement it. >>=20 >> So perhaps it would help if the document were simply clearer about = what it was asking of the DHCP server. Right now it's a bit vague=97all = the out-of-band or in-band querying is implied rather than explicitly = stated. This is part of what I was getting at by asking about real = expected use cases. > Thanks Ted - I agree that we need to make the document clearer. This = document should not be causing the refresh mechanics at a dhcp server or = client to change, and it shouldn't be asking the server to do something > fundamentally different from the kinds of things it already does in = order to satisfy the request. I don't think we really have anybody = asking for that, but we need to make the document clear so we're sure. = This is where I was > trying to focus the first part of the conversation (please do let me = know if what I had in that message was right > or not). >=20 > I'm going to take a stab at answering what I think you're asking for = real expected use cases. But be aware > of this context: >=20 > Email list conversations around how location references are created, = moved around, and consumed have been > notoriously difficult. It's easy to make assumptions, both as the = reader and writer, when trying to make short > points that lead folks to start talking passionately past each other. = I think that might have happened early > in the discussion of this document on this list. The way we've dealt = with it is to capture things in the drafts > (many now RFCs) in more detail. When things start to seem odd, please = refer back to those to see if they > clear up the oddness. A good touchstone starting place is RFC5808 = section 3 (including its subsections). > Because of the context, this is going to be verbose, and nit-sensitive = - please read it as an attempt to=20 > balance being specific with being concise. >=20 > The use case this draft is addressing is allowing a host to be = configured (via dhcp) with a reference to > a location object that it can hand off (convey) to other elements. If = those elements are able to use the > reference successfully, they get the location object and can use it as = part of whatever function they > are running (these elements are called location recipients). >=20 > The mechanism is intended to be general - there is no one specific = expected use case, but some of the > major instances used while developing the architecture include giving = an application on your (fixed) > desktop the ability to tell the local pizza delivery service where it = is, and your mobile phone the ability > to tell an emergency response center where it is. >=20 > The reference itself will not typically change rapidly - that's a = major advantage of using a reference instead > of providing location-by-value. If you had a deployment where you = didn't need to worry about who you've > given the reference to in the past, it could be configured once and = have a very long life. In a more general > deployment, the reference itself will need to occasionally change - = but note that it does so based on the > application use requirements, not inherently because the bits = (location) that the reference points to might > have changed. For instance, you might be willing to let some delivery = service know were you are right now, > but you don't want them to be able to use the reference you give them = next week. This is where the location > URI expiration notion becomes important - it lets the host know how = long the location server will honor > the reference. It lets the applications on the host make an informed = decision about who they expose the > reference to (I might be willing to give a reference to one of my = friends that's good for several days, but > I might choose not to hand one of those to the cab company in the city = I'm visiting).=20 >=20 > There are some applications where you don't want to give the same = reference to two different location recipients. > Those applications would be better served using a different location = configuration protocol than the one we're > talking about here, such as HELD (RFC5985). >=20 > Let me stop there and ask if I'm on a path to address your question or = if you were looking for something > completely different. >=20 > Given what's above, I'd like to reiterate the point the we should = clarify the draft to make it clear we're not > trying to change what a dhcp client or server does. How we fix how = it's trying to convey URI expiration needs > to get that part right. I don't think we should remove it from the = information that is configured, and I don't > think we should tie it to the lease time (either by making it being = exactly the lease time, or by artificially > stimulating refreshes based on it. Rather, this is a management = coordination task/policy decision for the > administrative domain. A reasonable Location Information Service that = is having its URIs configured into > hosts using dhcp should be configured to have the exipiry of those = URIs be at least as long as the expected > lease time. >=20 >=20 >> Robert, can you or James speak to that? I don't want you to feel = like I'm trying to checkmate you by getting you to admit to a use case = that's forbidden=97I don't think it's true that the use case I'm = reluctant to encourage is in fact forbidden. I just feel like right = now the way this is expected to be used is unstated and vague, and it = would be better if it were not. That is, it would be better for you to = really make a case for how you actually intend to use this option than = for us to gloss over it. >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From jmpolk@cisco.com Thu Mar 1 12:44:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE84321E832B for ; Thu, 1 Mar 2012 12:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.584 X-Spam-Level: X-Spam-Status: No, score=-109.584 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFwOA3SsJ4qN for ; Thu, 1 Mar 2012 12:44:16 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A5D8221E8329 for ; Thu, 1 Mar 2012 12:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=11724; q=dns/txt; s=iport; t=1330634656; x=1331844256; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=by5eM9+sROh/mNtg9Marh8swtAX/aqElz1cXLueidU8=; b=IIzF3eAyjfpOc9wZ39egDS7yKptJrfJIMgNHEr8JaLR8WLq9gwVQoWJV 7k2Aavtdh4vNts82Z3kolhkhsHs19gwwrGG0yeppBfRrHa6Xj86sj8F/q /jxDo4NjawqIBUAywIawtz/8bhu7IjVKvC3hZMazVhKzn/BIJ7wEeGvyE g=; X-IronPort-AV: E=Sophos;i="4.73,513,1325462400"; d="scan'208";a="33704869" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 01 Mar 2012 20:44:16 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q21KiEUf015850; Thu, 1 Mar 2012 20:44:14 GMT Message-Id: <201203012044.q21KiEUf015850@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Mar 2012 14:44:12 -0600 To: Alissa Cooper From: "James M. Polk" In-Reply-To: References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> <201112061938.pB6Jc3pD028634@mtv-core-3.cisco.com> <34043C82-5190-475B-8765-70B9C16FF4D7@nominum.com> <201112070104.pB71408l026419@mtv-core-2.cisco.com> <4EDFDB1C.3040102@nostrum.com> <4EE116DA.7000901@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org WG" , "James M. Polk" , Robert Sparks , Ted Lemon , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 20:44:17 -0000 Alissa thanks for the text offering. It looks good to me. If the DHCWG has consensus with it, I'll=20 incorporate it into the next rev and get that out before the -0X deadline. James At 12:52 PM 3/1/2012, Alissa Cooper wrote: >Picking this back up again in the hopes of achieving a resolution... > >I think we're close to consensus on the=20 >relationship (or lack thereof, I guess), between=20 >the lifetime of a location URI and DHCP refresh=20 >mechanics. I suggest the following edit to Section 2.3 to clarify this: > >=3D=3D=3D >OLD: > >The Valid-For (LuriType=3D2) indicates how long, in seconds, the > client is to consider this location URI (LuriType=3D1) valid > before performing a refresh of this Option, with a refreshed > LuriType=3D2 (Valid-For) value. A client will update its Location URI > either as part of the normal DHCP lease renewal, or through a > renewal request sent due to the Valid-For timer reaching the value > described in this document. Note that in the second case, the > request could ask only for the LocationURI option. > > The Valid-For (LuriType=3D2) offers no meaningful information without > an accompanying Location URI (LuriType=3D1), therefore a Valid-For > (LuriType=3D2) MUST NOT be sent without a Location URI (LuriType=3D1). > > If the Valid-For timer (LuriType=3D2) is received (solicited or > unsolicited), it is RECOMMENDED that the client refresh the Location > URI when the (Valid-For) counter value reaches approximately the > halfway point. For example, if 16000 was the initial value of the > Valid-For (LuriType=3D2) value, when 8000 seconds have passed, the > Option SHOULD be refreshed. However, if every client on a network > were to attempt a refresh at the same time, say if power when out > and was brought back up at the same time, there would be an > avalanche of location requests or transmissions. This can be avoided > by varying the timers between the nodes on the same network. This > can be a good reason for not giving out the same Valid-for timer > (amount) with each Location URI sent. > >NEW: > >The Valid-For (LuriType=3D2) indicates how long, in seconds, the > client is to consider this location URI=20 > (LuriType=3D1) valid. The choice of the Valid-For=20 > value is a policy decision for the domain=20 > administrator. It can be statically configured=20 > on the DHCP server or provisioned dynamically=20 > (via an out-of-band exchange with a Location=20 > Information Server) as requests for location=20 > URIs are received. Expiration of the Valid-For=20 > timeframe does not trigger an automatic refresh=20 > of the location URI or impinge on DHCP=20 > mechanics in any other way -- it merely informs=20 > the client of the URI's valid lifetime. > > The Valid-For (LuriType=3D2) offers no meaningful information without > an accompanying Location URI (LuriType=3D1), therefore a Valid-For > (LuriType=3D2) MUST NOT be sent without a Location URI (LuriType=3D1). >=3D=3D=3D > >If that satisfies the folks that have been=20 >discussing this, I think that concludes the DHC review of this document. > >Alissa > >On Dec 8, 2011, at 2:58 PM, Robert Sparks wrote: > > > On 12/8/11 11:27 AM, Ted Lemon wrote: > >> On Dec 7, 2011, at 4:31 PM, Robert Sparks wrote: > >>> If I have it right, the essence of (this=20 > part of) your concern is that a dhcp server can't be constrained > >>> to go ask an external process for the=20 > information it needs to respond to a request. That is, it needs > >>> to be able to respond to the request with=20 > the data it has at the time the request arrives. The operational > >>> model is that the data you have to respond=20 > with is the kind of stuff the server admin would enter as > >>> configuration (and it's possible that the=20 > admin would need to type very fast). It would be ok for an external > >>> process to be providing new information,=20 > but not ok to require the server to ask that external process for > >>> information (or wait on it if information became stale, etc.) > >> > >> So I've been ruminating about this since my=20 > rather terse response yesterday. I think it's=20 > inappropriate for me as an individual or as a=20 > working group chair to be the only one weighing=20 > in on this. I have some pretty strong=20 > opinions about what standards should require of=20 > DHCP servers, and I don't really think my=20 > opinions are inherently right=97they're just opinions. > >> > >> My essential concern about this document is=20 > that it seems to be placing expectations on a=20 > DHCP server that I think a typical DHCP server=20 > vendor would not be comfortable with. At the=20 > same time, it's also clear to me that there are=20 > DHCP servers out there that could certainly=20 > serve this data, even if they did an in-band=20 > query from another server to fetch it. I know=20 > Nominum's DHCP server can do this, and I am pretty sure CNR can do it as= well. > >> > >> So what I'm saying is that I don't really=20 > think it's wrong for a DHCP server to do=20 > this. My concern is that it might not be=20 > practical for an IETF document to effectively=20 > _require_ that a DHCP server do this. > >> > >> That's a fairly weak objection. If this=20 > document were to go through and become a=20 > standard, and people didn't want to implement=20 > it, they just wouldn't implement it. > >> > >> So perhaps it would help if the document=20 > were simply clearer about what it was asking of=20 > the DHCP server. Right now it's a bit=20 > vague=97all the out-of-band or in-band querying=20 > is implied rather than explicitly=20 > stated. This is part of what I was getting at=20 > by asking about real expected use cases. > > Thanks Ted - I agree that we need to make the=20 > document clearer. This document should not be=20 > causing the refresh mechanics at a dhcp server=20 > or client to change, and it shouldn't be asking the server to do something > > fundamentally different from the kinds of=20 > things it already does in order to satisfy the=20 > request. I don't think we really have anybody=20 > asking for that, but we need to make the=20 > document clear so we're sure. This is where I was > > trying to focus the first part of the=20 > conversation (please do let me know if what I had in that message was= right > > or not). > > > > I'm going to take a stab at answering what I=20 > think you're asking for real expected use cases. But be aware > > of this context: > > > > Email list conversations around how location=20 > references are created, moved around, and consumed have been > > notoriously difficult. It's easy to make=20 > assumptions, both as the reader and writer, when trying to make short > > points that lead folks to start talking=20 > passionately past each other. I think that might have happened early > > in the discussion of this document on this=20 > list. The way we've dealt with it is to capture things in the drafts > > (many now RFCs) in more detail. When things=20 > start to seem odd, please refer back to those to see if they > > clear up the oddness. A good touchstone=20 > starting place is RFC5808 section 3 (including its subsections). > > Because of the context, this is going to be=20 > verbose, and nit-sensitive - please read it as an attempt to > > balance being specific with being concise. > > > > The use case this draft is addressing is=20 > allowing a host to be configured (via dhcp) with a reference to > > a location object that it can hand off=20 > (convey) to other elements. If those elements are able to use the > > reference successfully, they get the location=20 > object and can use it as part of whatever function they > > are running (these elements are called location recipients). > > > > The mechanism is intended to be general -=20 > there is no one specific expected use case, but some of the > > major instances used while developing the=20 > architecture include giving an application on your (fixed) > > desktop the ability to tell the local pizza=20 > delivery service where it is, and your mobile phone the ability > > to tell an emergency response center where it is. > > > > The reference itself will not typically=20 > change rapidly - that's a major advantage of using a reference instead > > of providing location-by-value. If you had a=20 > deployment where you didn't need to worry about who you've > > given the reference to in the past, it could=20 > be configured once and have a very long life. In a more general > > deployment, the reference itself will need to=20 > occasionally change - but note that it does so based on the > > application use requirements, not inherently=20 > because the bits (location) that the reference points to might > > have changed. For instance, you might be=20 > willing to let some delivery service know were you are right now, > > but you don't want them to be able to use the=20 > reference you give them next week. This is where the location > > URI expiration notion becomes important - it=20 > lets the host know how long the location server will honor > > the reference. It lets the applications on=20 > the host make an informed decision about who they expose the > > reference to (I might be willing to give a=20 > reference to one of my friends that's good for several days, but > > I might choose not to hand one of those to=20 > the cab company in the city I'm visiting). > > > > There are some applications where you don't=20 > want to give the same reference to two different location recipients. > > Those applications would be better served=20 > using a different location configuration protocol than the one we're > > talking about here, such as HELD (RFC5985). > > > > Let me stop there and ask if I'm on a path to=20 > address your question or if you were looking for something > > completely different. > > > > Given what's above, I'd like to reiterate the=20 > point the we should clarify the draft to make it clear we're not > > trying to change what a dhcp client or server=20 > does. How we fix how it's trying to convey URI expiration needs > > to get that part right. I don't think we=20 > should remove it from the information that is configured, and I don't > > think we should tie it to the lease time=20 > (either by making it being exactly the lease time, or by artificially > > stimulating refreshes based on it. Rather,=20 > this is a management coordination task/policy decision for the > > administrative domain. A reasonable Location=20 > Information Service that is having its URIs configured into > > hosts using dhcp should be configured to have=20 > the exipiry of those URIs be at least as long as the expected > > lease time. > > > > > >> Robert, can you or James speak to that? I=20 > don't want you to feel like I'm trying to=20 > checkmate you by getting you to admit to a use=20 > case that's forbidden=97I don't think it's true=20 > that the use case I'm reluctant to encourage is=20 > in fact forbidden. I just feel like right now=20 > the way this is expected to be used is unstated=20 > and vague, and it would be better if it were=20 > not. That is, it would be better for you to=20 > really make a case for how you actually intend=20 > to use this option than for us to gloss over it. > >> > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Mar 1 12:50:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E39921E8032 for ; Thu, 1 Mar 2012 12:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVxV4RNSkWJg for ; Thu, 1 Mar 2012 12:50:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8E21E8019 for ; Thu, 1 Mar 2012 12:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=12222; q=dns/txt; s=iport; t=1330635057; x=1331844657; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Vu1TNCxdqwgG0bnJjIF1+HI9K1gjbDUNRcvuXfB42Zk=; b=m9LDyfSY3fMN8loCmhTHnEVGDs7Scc8JilyZ/DRhLC4tfp8FB1s/RNA9 S831rNwl369N/IxSp1NTy5YWNGQ8gynvqBfJjmnbg5WXd0357oAu2xspk Fhm/r2EI/3m0QA7WyxKqHyiR61yzxC4wZFkiI3dd4FaevUkD9mPN/Js7F s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFfgT0+tJV2Z/2dsb2JhbABDglGxQoEHgX0BAQEEEgEJEQNJEAIBCBEEAQELBhcBBgEgJQkIAgQBEggTB4dkoGABln2JG4NzDQVQGAYDAoRkYA4RBBSCTmMEiE+YB4d2 X-IronPort-AV: E=Sophos;i="4.73,513,1325462400"; d="scan'208,217";a="63116845" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 01 Mar 2012 20:50:55 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q21KotKF012756; Thu, 1 Mar 2012 20:50:55 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 14:50:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF7EC.FEF3C276" Date: Thu, 1 Mar 2012 14:50:53 -0600 Message-ID: In-Reply-To: <4B5DAD0F-2B92-4D38-BD62-A8E3515A50C4@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Thread-Index: AQHM637zaQSetMIgNES1IZjReImPDpY9ruaAgAGcaYCAABpFAIAAF1eAgAAFrICAFoR1AIAAEI8A///qWYA= References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> <4B5DAD0F-2B92-4D38-BD62-A8E3515A50C4@nominum.com> From: "Bernie Volz (volz)" To: "Ted Lemon" , "Huan Huan" X-OriginalArrivalTime: 01 Mar 2012 20:50:55.0494 (UTC) FILETIME=[FF540260:01CCF7EC] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 20:50:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF7EC.FEF3C276 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, not yet. =20 There are really two drafts that COULD be considered: 1. A problem statement (with or without possible solutions)=20 2. A solution statement (without or with possible solutions) - which would detail why the solution (out of a possible set) was chosen. =20 - Bernie =20 From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, March 01, 2012 9:05 AM To: Huan Huan Cc: Bernie Volz (volz); Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm =20 On Mar 1, 2012, at 8:05 AM, Huan Huan wrote: I really want to know the end of this issue? Should we need to modify RFC3633 or we need a new draft? =20 Do we know what a new draft would say? =20 =20 ------_=_NextPart_001_01CCF7EC.FEF3C276 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, not yet.

 

There are really two drafts that COULD be = considered:

1.       = A problem statement (with or without possible solutions) =

2.       = A solution statement (without or with possible solutions) – = which would detail why the solution (out of a possible set) was = chosen.

 

-          = Bernie

 

From:= = Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Thursday, = March 01, 2012 9:05 AM
To: Huan Huan
Cc: Bernie Volz = (volz); <dhcwg@ietf.org>
Subject: Re: [dhcwg] dhcwg = Digest, DHCP Renew vs Confirm

 

On = Mar 1, 2012, at 8:05 AM, Huan Huan <shawngespan@gmail.com> = wrote:

I really want to know the end of this issue? Should we need to modify = RFC3633 or we need a new = draft?

 

Do we know what a new draft would = say?

 

 

------_=_NextPart_001_01CCF7EC.FEF3C276-- From shawngespan@gmail.com Thu Mar 1 18:20:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5521E8098 for ; Thu, 1 Mar 2012 18:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.838 X-Spam-Level: X-Spam-Status: No, score=0.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, MIME_HTML_ONLY_MULTI=0.001, MPART_ALT_DIFF=0.739, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvPOq2ubUZ8N for ; Thu, 1 Mar 2012 18:20:37 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4921E804F for ; Thu, 1 Mar 2012 18:20:37 -0800 (PST) Received: by dakl33 with SMTP id l33so1657088dak.31 for ; Thu, 01 Mar 2012 18:20:37 -0800 (PST) Received-SPF: pass (google.com: domain of shawngespan@gmail.com designates 10.68.212.232 as permitted sender) client-ip=10.68.212.232; Authentication-Results: mr.google.com; spf=pass (google.com: domain of shawngespan@gmail.com designates 10.68.212.232 as permitted sender) smtp.mail=shawngespan@gmail.com; dkim=pass header.i=shawngespan@gmail.com Received: from mr.google.com ([10.68.212.232]) by 10.68.212.232 with SMTP id nn8mr9929436pbc.156.1330654837619 (num_hops = 1); Thu, 01 Mar 2012 18:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:subject:in-reply-to:x-mailer :mime-version:content-type; bh=pse8OYsMqDFarQLv3Xc8+BF/TJrmzMokub4aJnugbWA=; b=wlPy/vedF0h7wrsxkiFtLCEkPQXnRRWZLsFzX1LX+E786JBdoEA3Iun+acm7uIi6/2 WvPf1GJDgGMY6oGI+762yRYbJqLGsac7W3F8+wCyHVYeXhyFP95PZfi7/vcR8YDQ3lzO nGJmexydiS8OxKVXzlRtV/4edqGj7S35ltwnT+eqxh226jvTcmIjrnTQEng7lUm3Swf/ gDXDuLAIsJXX7XVXiZcIDK6AbP7k9gZK/we2XO6Zy5sRJhZXwKPuzeJDsxVzuLeXtWc/ 8fer9HbTAaQ6HfeA/EpqrFxorZ4UxU0sjAwm7+k/hgTbfAYHNsmHM1kBStjro2qqHjNu nNIQ== Received: by 10.68.212.232 with SMTP id nn8mr8204728pbc.156.1330654837513; Thu, 01 Mar 2012 18:20:37 -0800 (PST) Received: from www.palm.com ([58.214.236.154]) by mx.google.com with ESMTPS id q1sm3610647pbv.49.2012.03.01.18.20.31 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 18:20:36 -0800 (PST) Message-ID: <4f502e74.214a440a.2351.fffff2d9@mx.google.com> Date: Sun, 26 Feb 2012 12:36:28 +0800 From: To: "Ted Lemon" In-Reply-To: <4B5DAD0F-2B92-4D38-BD62-A8E3515A50C4@nominum.com> X-Mailer: Palm webOS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Alternative_=_Boundary_=_1330230984" Cc: "" , "Bernie Volz \(volz\)" Subject: [dhcwg] =?utf-8?b?562U5aSN77yaIFJlOiAgZGhjd2cgRGlnZXN0LCBESENQ?= =?utf-8?q?_Renew_vs_Confirm?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 02:20:38 -0000 --Alternative_=_Boundary_=_1330230984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could a device be a dhcp requesrting router and dhcp client at a same time,= I mean in a process? 

-- =E5=8F=91=E8=87=AA=E6= =88=91=E7=9A=84 HP TouchPad
T= ed Lemon<Ted.Lemon@nominum.com>=E4=BA=8E3=E6=9C=88 1, 2012 22:04=E5= =86=99=E9=81=93=EF=BC=9A
=0A=0A=0A=0A=0A
=0A
On Mar 1, 2= 012, at 8:05 AM, Huan Huan <sha= wngespan@gmail.com> wrote:
=0A
=0A
=0AI really w= ant to know the end of this issue? Should we need to modify RFC3633 or we n= eed a new draft?
=0A
=0A
=0A
=0A
Do we know wh= at a new draft would say?
=0A

=0A
=0A
=0A=0A=0A --Alternative_=_Boundary_=_1330230984-- From Ted.Lemon@nominum.com Thu Mar 1 19:51:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6295321E806B for ; Thu, 1 Mar 2012 19:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=-2.907, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IkcLObPT6uM for ; Thu, 1 Mar 2012 19:51:27 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 76B3521E8032 for ; Thu, 1 Mar 2012 19:51:27 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT1BDvh2+o6h0LuXv+PzeNaVSArB+iIEc@postini.com; Thu, 01 Mar 2012 19:51:27 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5FAB51B83E8 for ; Thu, 1 Mar 2012 19:51:26 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5221319005C; Thu, 1 Mar 2012 19:51:26 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 1 Mar 2012 19:51:26 -0800 From: Ted Lemon To: " " Thread-Topic: =?big5?B?tarOYKFHIFJlOiBbZGhjd2ddIGRoY3dnIERpZ2VzdCwgREhDUCBSZW5ldyB2cyBD?= =?big5?Q?onfirm?= Thread-Index: AQHM637zaQSetMIgNES1IZjReImPDpY9ruaAgAGcaYCAABpFAIAAF1eAgAAFrICAFoR1AIAAEI8A//kX7ACAB88RgA== Date: Fri, 2 Mar 2012 03:51:25 +0000 Message-ID: References: <4f502e74.214a440a.2351.fffff2d9@mx.google.com> In-Reply-To: <4f502e74.214a440a.2351.fffff2d9@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_FF1A63FD4A5A4F2C92B91C1D4D40F582nominumcom_" MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] =?big5?b?tarOYKFHIFJlOiAgZGhjd2cgRGlnZXN0LCBESENQIFJlbmV3?= =?big5?b?IHZzIENvbmZpcm0=?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 03:51:28 -0000 --_000_FF1A63FD4A5A4F2C92B91C1D4D40F582nominumcom_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 T24gRmViIDI1LCAyMDEyLCBhdCAxMTozNiBQTSwgPHNoYXduZ2VzcGFuQGdtYWlsLmNvbTxtYWls dG86c2hhd25nZXNwYW5AZ21haWwuY29tPj4NCiA8c2hhd25nZXNwYW5AZ21haWwuY29tPG1haWx0 bzpzaGF3bmdlc3BhbkBnbWFpbC5jb20+PiB3cm90ZToNCkNvdWxkIGEgZGV2aWNlIGJlIGEgZGhj cCByZXF1ZXNydGluZyByb3V0ZXIgYW5kIGRoY3AgY2xpZW50IGF0IGEgc2FtZSB0aW1lLCBJIG1l YW4gaW4gYSBwcm9jZXNzPw0KDQpTdXJlLiAgIFdoeSBub3Q/DQoNCg== --_000_FF1A63FD4A5A4F2C92B91C1D4D40F582nominumcom_ Content-Type: text/html; charset="big5" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 25, 2012, at 11:36 PM, <shawngespan@gmail.com>
C= ould a device be a dhcp requesrting router and dhcp client at a same time, I me= an in a process? 

Sure.   Why not?

--_000_FF1A63FD4A5A4F2C92B91C1D4D40F582nominumcom_-- From mellon@fugue.com Mon Mar 5 15:39:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325B721F8664; Mon, 5 Mar 2012 15:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7zVoYO7iZNK; Mon, 5 Mar 2012 15:39:36 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 00CF321F85A0; Mon, 5 Mar 2012 15:39:36 -0800 (PST) Received: from [IPv6:2001:470:1f07:1486:3912:d05:2bd3:9497] (unknown [IPv6:2001:470:1f07:1486:3912:d05:2bd3:9497]) by toccata.fugue.com (Postfix) with ESMTPSA id 325662382178; Mon, 5 Mar 2012 18:39:33 -0500 (EST) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_34A1AE4E-28CA-48A1-A1E0-181B0B5CF1A4" Date: Mon, 5 Mar 2012 18:39:32 -0500 References: <20120305231736.20673.74948.idtracker@ietfa.amsl.com> To: " WG" , "dnsop@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) X-Mailer: Apple Mail (2.1426) Subject: [dhcwg] Fwd: I-D Action: draft-lemon-dhc-dns-pd-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:39:37 -0000 --Apple-Mail=_34A1AE4E-28CA-48A1-A1E0-181B0B5CF1A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just submitted a draft that talks about mechanisms for populating the = reverse tree for prefixes delegated using RFC3633. It's not complete = (I haven't documented the format of the options, for instance), but it = walks through all the scenarios that I think are relevant and (I think) = completely specifies how the requesting router and delegating router = should interact. The document takes no position on whether populating the reverse tree is = a good idea; rather, it provides mechanisms for service providers and = site administrators to populate the reverse tree if they choose to, or = request that it not be populated if they prefer. I think we got bogged down in the discussion of whether the reverse tree = should be populated or not, which is an interesting discussion, and so a = lot of what's in the document probably got talked about in the dnsop = working group, but I don't think anyone ever wrote it down in a draft. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-lemon-dhc-dns-pd-00.txt > Date: March 5, 2012 6:17:36 PM EST > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Populating the DNS Reverse Tree for DHCP = Delegated Prefixes > Author(s) : Ted Lemon > Filename : draft-lemon-dhc-dns-pd-00.txt > Pages : 18 > Date : 2012-03-05 >=20 > This document describes three alternatives for populating the DNS > reverse tree for prefixes delegated using DHCP, and provides > mechanisms for implementing each alternative. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lemon-dhc-dns-pd-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-lemon-dhc-dns-pd-00.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_34A1AE4E-28CA-48A1-A1E0-181B0B5CF1A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = just submitted a draft that talks about mechanisms for populating the = reverse tree for prefixes delegated using RFC3633.   It's not = complete (I haven't documented the format of the options, for instance), = but it walks through all the scenarios that I think are relevant and (I = think) completely specifies how the requesting router and delegating = router should interact.

The document takes no = position on whether populating the reverse tree is a good idea; rather, = it provides mechanisms for service providers and site administrators to = populate the reverse tree if they choose to, or request that it not be = populated if they prefer.

I think we got bogged = down in the discussion of whether the reverse tree should be populated = or not, which is an interesting discussion, and so a lot of what's in = the document probably got talked about in the dnsop working group, but I = don't think anyone ever wrote it down in a draft.

Begin = forwarded message:

Subject: I-D Action: = draft-lemon-dhc-dns-pd-00.txt
Date: March 5, 2012 = 6:17:36 PM EST
Reply-To: = internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.

Title =           : Populating = the DNS Reverse Tree for DHCP Delegated Prefixes
Author(s) =       : Ted Lemon
Filename =        : = draft-lemon-dhc-dns-pd-00.txt
Pages =           : = 18
= Date =            : = 2012-03-05

  This document describes three = alternatives for populating the DNS
  reverse tree for = prefixes delegated using DHCP, and provides
  mechanisms = for implementing each alternative.


A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lemon-dhc-dns-pd-00.txt
=
Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-lemon-dhc-dns-pd-00.txt
_______________________________________________
I-D-Announce = mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=
= --Apple-Mail=_34A1AE4E-28CA-48A1-A1E0-181B0B5CF1A4-- From leaf.y.yeh@huawei.com Tue Mar 6 00:17:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04CF21E80AE for ; Tue, 6 Mar 2012 00:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.651 X-Spam-Level: X-Spam-Status: No, score=-6.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R83diaZrUME for ; Tue, 6 Mar 2012 00:17:21 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1B50621E808C for ; Tue, 6 Mar 2012 00:17:21 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00LXEEXRUH@szxga03-in.huawei.com> for dhcwg@ietf.org; Tue, 06 Mar 2012 16:15:27 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00LFCEX9Z7@szxga03-in.huawei.com> for dhcwg@ietf.org; Tue, 06 Mar 2012 16:15:27 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHP76289; Tue, 06 Mar 2012 16:15:26 +0800 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 16:15:17 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.199]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Tue, 06 Mar 2012 16:15:19 +0800 Date: Tue, 06 Mar 2012 08:15:20 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: dhc WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt Thread-index: AQHM+rJ5wB5yedLmdUWX9jy95pvuKZZc55Hw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:17:22 -0000 Dear WG, A new draft named "Authorization Option for DHCPv6 Relay Agents on Broadband Access Server" has been posted yesterday. Questions and comments on it are more than welcome. Best Regards, Leaf -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, March 05, 2012 5:26 PM To: Leaf yeh Subject: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt A new version of I-D, draft-yeh-dhc-dhcpv6-authorization-opt-00.txt has been successfully submitted by Leaf Y. Yeh and posted to the IETF repository. Filename: draft-yeh-dhc-dhcpv6-authorization-opt Revision: 00 Title: Authorization Option for DHCPv6 Relay Agents on Broadband Access Server Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 9 Abstract: The DHCPv6 authorization option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information got from the centralized RADIUS server which is not located at the same place of DHCPv6 server in the case when the NAS works as DHCPv6 relay agent and RADIUS client simultaneously. The IETF Secretariat From Francis.Dupont@fdupont.fr Tue Mar 6 03:54:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642F821F8843 for ; Tue, 6 Mar 2012 03:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFtM4M6HyH0i for ; Tue, 6 Mar 2012 03:54:21 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id B287B21F8833 for ; Tue, 6 Mar 2012 03:54:12 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q26BsB6n046426 for ; Tue, 6 Mar 2012 12:54:11 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203061154.q26BsB6n046426@givry.fdupont.fr> From: Francis Dupont To: dhcwg@ietf.org Date: Tue, 06 Mar 2012 12:54:11 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [dhcwg] about draft-ietf-dhc-dhcpv4-over-ipv6-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:54:21 -0000 I have some comments about draft-ietf-dhc-dhcpv4-over-ipv6-00.txt: - first, these are from implementation feedback - but this doesn't mean I have good ideas about real world use cases (:-) - it is not clear in the introduction but this can work only for DHCPv4 messages, not legacy BOOTP messages (in the case BOOTP itself is still used?) - the document requires the CRA to be colocated with the client, in fact it works well when the client is directly attached, i.e., "on the same link" is enough - the CRA MUST NOT include an option 82 (RAI): this really limits the CRA service, for instance a CRA can't serve more than one link (but it is already limited to colocated and with multiple IPv6 source addresses it is easy to run several CRAs on the same box) - the choice of the ports should be explained, in particular I'd like to understand "A CRA also listens for DHCP packets on IPv6 UDP port 68." (note I have no concern about the choice itself). Regards Francis.Dupont@fdupont.fr PS: I implemented CRA, TRA, TSV and TSV+normal (i.e., the "A TSV can also listen on IPv4 UDP port 67 like a normal DHCPv4 server"). And BTW wireshark is fine enough to ignore the IP version when it dissects UDP port 67/68 packets as DHCPv4. From mellon@fugue.com Tue Mar 6 15:57:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9E21E8049 for ; Tue, 6 Mar 2012 15:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cngaKglP0rbd for ; Tue, 6 Mar 2012 15:57:09 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC321E800F for ; Tue, 6 Mar 2012 15:57:09 -0800 (PST) Received: from [IPv6:2001:470:1f07:1486:b985:c3a2:b53e:db9e] (unknown [IPv6:2001:470:1f07:1486:b985:c3a2:b53e:db9e]) by toccata.fugue.com (Postfix) with ESMTPSA id 6FA22238217C for ; Tue, 6 Mar 2012 18:57:07 -0500 (EST) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_F376097B-A6D8-4BC5-A922-F3818344F50A" Date: Tue, 6 Mar 2012 18:57:06 -0500 References: <20120306150141.8315.38572.idtracker@ietfa.amsl.com> To: " WG" Message-Id: <31E06AFC-78DC-4DAA-96DC-FA82E18AD212@fugue.com> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) X-Mailer: Apple Mail (2.1426) Subject: [dhcwg] Fwd: Last Call: (SAVI Solution for DHCP) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 23:57:10 -0000 --Apple-Mail=_F376097B-A6D8-4BC5-A922-F3818344F50A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This draft has never been formally reviewed by the DHC working group. = It's in IETF last call. Jari asked me to ask for review back in = January, and I read it myself and corresponded briefly with the authors, = but then managed to forget to ask the working group as a whole to review = it. If anybody has time, I'd really appreciate it if you could give the = document a read. Begin forwarded message: > From: The IESG > Subject: Last Call: (SAVI Solution for = DHCP) to Proposed Standard > Date: March 6, 2012 10:01:41 AM EST > To: IETF-Announce > Cc: savi@ietf.org > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from the Source Address Validation > Improvements WG (savi) to consider the following document: > - 'SAVI Solution for DHCP' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-03-20. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document specifies the procedure for creating bindings between = a > DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a > binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address > Validation Improvements) device. The bindings can be used to filter > packets generated on the local link with forged source IP address. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail=_F376097B-A6D8-4BC5-A922-F3818344F50A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = draft has never been formally reviewed by the DHC working group.   = It's in IETF last call.   Jari asked me to ask for review back in = January, and I read it myself and corresponded briefly with the authors, = but then managed to forget to ask the working group as a whole to review = it.

If anybody has time, I'd really appreciate it if = you could give the document a read.

Begin forwarded = message:

From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-savi-dhcp-12.txt> = (SAVI Solution for DHCP) to Proposed Standard
Date: March 6, 2012 = 10:01:41 AM EST
To: IETF-Announce <ietf-announce@ietf.org>
<= /span>
Reply-To: = ietf@ietf.org

<= br>The IESG has received a request from the Source Address = Validation
Improvements WG (savi) to consider the following = document:
- 'SAVI Solution for DHCP'
=  <draft-ietf-savi-dhcp-12.txt> as a Proposed = Standard

The IESG plans to make a decision in the next few weeks, = and solicits
final comments on this action. Please send substantive = comments to the
ietf@ietf.org = mailing lists by 2012-03-20. Exceptionally, comments may be
sent to = iesg@ietf.org instead. In either = case, please retain the
beginning of the Subject line to allow = automated sorting.

Abstract


  This document = specifies the procedure for creating bindings between a
=   DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address = and a
  binding anchor [I-D.ietf-savi-framework] on SAVI = (Source Address
  Validation Improvements) device. The = bindings can be used to filter
  packets generated on the = local link with forged source IP address.




The file = can be obtained via
http://data= tracker.ietf.org/doc/draft-ietf-savi-dhcp/

IESG discussion = can be tracked = via
http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/ballot/

No IPR declarations have been submitted directly on this = I-D.


_______________________________________________
IETF-An= nounce mailing = list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ie= tf-announce

= --Apple-Mail=_F376097B-A6D8-4BC5-A922-F3818344F50A-- From internet-drafts@ietf.org Tue Mar 6 19:39:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC57E21E8043; Tue, 6 Mar 2012 19:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDlGZPYkBT5i; Tue, 6 Mar 2012 19:39:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0491A21E8013; Tue, 6 Mar 2012 19:38:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120307033858.24455.93295.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 19:38:58 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 03:39:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Secure DHCPv6 Using CGAs Author(s) : Sheng Jiang Sean Shen Filename : draft-ietf-dhc-secure-dhcpv6-05.txt Pages : 15 Date : 2012-03-06 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attack. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism based on using CGAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-05.txt From thuth@de.ibm.com Wed Mar 7 01:23:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808AC21F878E for ; Wed, 7 Mar 2012 01:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxcnoBkjTZUf for ; Wed, 7 Mar 2012 01:23:39 -0800 (PST) Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by ietfa.amsl.com (Postfix) with ESMTP id 57EBC21F8789 for ; Wed, 7 Mar 2012 01:23:39 -0800 (PST) Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Mar 2012 09:23:36 -0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (9.149.38.129) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 7 Mar 2012 09:23:33 -0000 Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q279NW7T2568192 for ; Wed, 7 Mar 2012 09:23:32 GMT Received: from d06av12.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q279NVlM012427 for ; Wed, 7 Mar 2012 02:23:31 -0700 Received: from d06ml032.portsmouth.uk.ibm.com (d06ml032.portsmouth.uk.ibm.com [9.149.76.137]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q279NVVN012420; Wed, 7 Mar 2012 02:23:31 -0700 In-Reply-To: <20120307033858.24455.93295.idtracker@ietfa.amsl.com> References: <20120307033858.24455.93295.idtracker@ietfa.amsl.com> X-KeepSent: C618F02C:B453F8C5-C12579BA:002F8E72; type=4; name=$KeepSent To: dhcwg@ietf.org X-Mailer: Lotus Notes Release 8.5.2FP3 Aug 10, 2010 Message-ID: From: Thomas Huth Date: Wed, 7 Mar 2012 10:23:13 +0100 X-MIMETrack: Serialize by Router on D06ML032/06/M/IBM(Release 8.5.2FP3|July 10, 2011) at 07/03/2012 10:23:25 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII x-cbid: 12030709-0342-0000-0000-000001192689 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 09:23:40 -0000 Hi, I quickly read through your draft, I like the idea, but I also have some remarks / questions: Section 1. : "... thus the address of a DHCPv6 message sender, which can be a DHCPv6 server, a relay agent or a client, is able to be verified by a receiver." I'd suggest to replace "is able to be verified" with "can be verified". Section 4.: You've got a very long quote from RFC3972 here: "CGAs are IPv6 addresses ..." I think you don't have to do that. If somebody does not know RFC3972 yet, he or she can read that RFC, so no need to bloat your draft by repeating this here. "It assumes the secured DHCPv6 message sender has already haven CGAs" What do you mean by "haven" CGAs here? "and the receiver has already been given the CGAs of the sender." How could that have happened? By out-of-band, manual configuration again? "can verify both the CGA and signature, then process the payload of the DHCPv6 message only if the validation is successful. " That part of the sentence is repeated twice, on page 4 and 5 Section 5.2: Why do you need a "Padding" field in this option? AFAIK according to RFC 3315 there should not be any padding between the options. Regards, T. Huth dhcwg-bounces@ietf.org wrote on 07.03.2012 04:38:58: > 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 : Secure DHCPv6 Using CGAs > Author(s) : Sheng Jiang > Sean Shen > Filename : draft-ietf-dhc-secure-dhcpv6-05.txt > Pages : 15 > Date : 2012-03-06 > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables > DHCPv6 servers to pass configuration parameters. It offers > configuration flexibility. If not secured, DHCPv6 is vulnerable to > various attacks, particularly spoofing attack. This document analyzes > the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism > based on using CGAs. From Jeff.Hodges@KingsMountain.com Wed Mar 7 11:18:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C7811E807F for ; Wed, 7 Mar 2012 11:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.141 X-Spam-Level: X-Spam-Status: No, score=-100.141 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OXb68ebKVTa for ; Wed, 7 Mar 2012 11:18:21 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 2644F11E8072 for ; Wed, 7 Mar 2012 11:18:21 -0800 (PST) Received: (qmail 14698 invoked by uid 0); 7 Mar 2012 19:18:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 7 Mar 2012 19:18:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Y6RdyuF7CQytWlC4ohpxrt9ZSGbajO2K7GSfHr2aLdE=; b=wdTHLYUB+HE9o94dFejbYBPb0K4nXY724sr6OTIgm0g4xG1pNq/QTCTmN+xMe7Mb1CGwHIJ7Z5yJyxaBfBaAb6WtE+WBDUYzV0KlELqAUYny5re8n/grz6EzL5+iv1IQ; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S5MNO-0003Kg-8s; Wed, 07 Mar 2012 12:18:18 -0700 Message-ID: <4F57B476.1000808@KingsMountain.com> Date: Wed, 07 Mar 2012 11:18:14 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: Julian Reschke , Mark Nottingham Subject: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:18:22 -0000 fyi, I ran across this article.. Big Changes Coming To Wi-Fi By Stewart Wolpin Published Feb 6, 2012 http://tech.lifegoesstrong.com/print/article/big-changes-coming-wi-fi =2E.which points off to this stuff.. Bringing the Cellular Roaming Experience to Wi-Fi http://blogs.cisco.com/tag/hotspot-2-0/ The Future of Hotspots: Making Wi-Fi as Secure and Easy to Use as Cellula= r https://www.cisco.com/en/US/solutions/collateral/ns341/ns524/ns673/white_= paper_c11-649337.html https://www.cisco.com/en/US/solutions/collateral/ns341/ns524/ns673/white_= paper_c11-649337.pdf =2E.which has these sections (attached below).. Next-Generation Hotspot Network Discovery and Selection MSAP: Making Next-Generation Hotspots Even Better with New Service and Revenue Opportunities =2E.which seems to me to address (if deployed in hotspots and clients) th= e=20 "captive portal" issue. what do you folks think? thanks, =3DJeffH ------ Next-Generation Hotspot Network Discovery and Selection IEEE 802.11u, the amendment addressing "Interworking with External Networ= ks,"=20 was completed by the 802.11u task group in mid-2010 and approved by the I= EEE=20 for publication in February 2011. The purpose of the amendment is to prov= ide an=20 effective interface between an IEEE 802.11 access network and carrier net= works.=20 The amendment adds to IEEE 802.11 the following services (this is not a=20 comprehensive list): =95 Network discovery and selection =96 Provides for the discovery of suitable networks (preassociation) thro= ugh the=20 advertisement of access network type {private network, free public networ= k,=20 for-fee public network}, roaming consortium, and venue information. =96 Generic Advertisement Service (GAS), which provides for Layer 2 trans= port of=20 an advertisement protocol's frames between a mobile device and a server i= n the=20 network prior to authentication. The access point is responsible for the = relay=20 of a mobile device's query to a server in the carrier's network and for=20 delivering the server's response back to the mobile. =96 Provides Access Network Query Protocol (ANQP), which is a query and r= esponse=20 protocol used by a mobile device to discover a range of information, incl= uding=20 the hotspot operator's domain name (a globally unique, machine searchable= data=20 element); roaming partners accessible via the hotspot along with their=20 credential type and EAP method supported for authentication; IP address t= ype=20 availability (for example, IPv4, IPv6); and other metadata useful in a mo= bile=20 device's network selection process. =95 QoS map distribution. This provides a mapping between the IP's differ= entiated=20 services code point (DSCP) to over-the-air Layer 2 priority on a per-devi= ce=20 basis, facilitating end-to-end QoS. The following is an exemplary, simplified sequence of events used by an I= EEE=20 802.11u-capable mobile device to authenticate with a hotspot: 1. The mobile device comes within radio range of one or more hotspots and= =20 receives their beacons. These beacons indicate support for the IEEE 802.1= 1u=20 protocol via the Interworking element. The SSID element in the beacon pro= vides=20 the Wi-Fi network name. (In the next steps, it's assumed that the mobile = device=20 doesn't recognize any of the received SSIDs.) 2. The mobile device uses GAS to post an ANQP query to an access point fr= om=20 each of the SSIDs discovered in step 1. In response, each access point pr= ovides=20 the hotspot operator's domain name and network access identifier (NAI) Re= alm list. 3. The mobile device next retrieves its credential from local storage to = get=20 the realm with which it can authenticate. The mobile device then compares= that=20 realm to the list of roaming partner's realms it retrieved in step 2 (in = the=20 NAI Realm list). If there is a match, the mobile device knows it should b= e able=20 to successfully authenticate with that network. If there is more than one= =20 match, the mobile device uses operator policy to determine which Wi-Fi ne= twork=20 to join. 4. The mobile device next retrieves its operator policy for network selec= tion=20 from local storage and looks up an ordered list of preference level and d= omain=20 name pairs for each of its roaming partners. The mobile device then compa= res=20 the hotspot operator's domain names received in step 2 with this list and= =20 selects the network having the highest preference level. 5. The mobile device authenticates to that network using its credential. = In=20 cases where the mobile device is in possession of more than one credentia= l (for=20 example, the mobile has a SIM and username/password credentials), it can = use=20 the NAI Realm list to learn the acceptable credential type(s) and EAP met= hod(s). As we've just described, using ANQP with GAS, a mobile device can query t= he=20 network prior to authentication to determine if the hotspot is operated b= y one=20 of its roaming partners, as well as the EAP method and credential type to= use.=20 A mobile device's connection manager can now autonomously (that is, witho= ut=20 user intervention) determine which hotspot to select taking into account = operator policies, authenticate to that Wi-Fi network, and establish link= -layer=20 security using WPA2-Enterprise. Wi-Fi has become as easy-to-use and as se= cure=20 as 3G cellular! MSAP: Making Next-Generation Hotspots Even Better with New Service and Re= venue=20 Opportunities Many venues that have deployed Wi-Fi access networks don't fall under the= =20 colloquial definition of hotspot (such as coffee shops, airports, and hot= els).=20 For example, Wi-Fi is being deployed in sports stadiums, retail shopping = malls,=20 and other public places. Often, these venues wish to deploy local service= s not=20 accessible through the public Internet. Increasingly, carriers are operat= ing=20 these networks on behalf of venue owners as part of a managed service off= ering. Mobility Services Advertisement Protocol (MSAP) is a protocol for service= =20 discovery, enabling the connection of users to venue services. Because MS= AP is=20 transported via IEEE 802.11u GAS, mobile devices can query for local serv= ices=20 prior to authenticating to a Wi-Fi network. Mobile devices performing an = MSAP=20 query securely retrieve icons and service URLs; the mobile device's UI di= splays=20 the icons (when enabled/requested by the user). When the user clicks on t= he=20 icon, the mobile device launches an application, such as a browser to the= URL,=20 thereby accessing the service. In so doing, users are securely, easily, a= nd=20 immediately connected to venue-based services. Examples of such services = in a=20 stadium include display of a stadium map showing food kiosks and restroom= s,=20 looking up player statistics, and watching instant replays. MSAP messages are Simple Object Access Protocol (SOAP) methods carrying X= ML=20 payloads. An MSAP client (software on the mobile device) queries an MSAP = server=20 for service advertisements. Service advertisements include an icon, URL, = related metadata, and a digital signature. The XML digital signature is u= sed to=20 verify the authenticity and integrity of the service advertisements. This= is=20 critical, as service advertisements are delivered prior to authentication= ;=20 therefore, there is no Layer 2 security association that can protect thei= r=20 integrity. --- end From dankney@network1.net Wed Mar 7 12:24:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4440411E8098 for ; Wed, 7 Mar 2012 12:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn9eNJgZxmTN for ; Wed, 7 Mar 2012 12:24:04 -0800 (PST) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id A931F11E8094 for ; Wed, 7 Mar 2012 12:24:04 -0800 (PST) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 9A662542810 for ; Wed, 7 Mar 2012 15:24:03 -0500 (EST) Date: Wed, 07 Mar 2012 15:24:03 -0500 (EST) From: perl-list To: dhcwg@ietf.org Message-ID: <72ca9fbb-5721-466d-976d-0cbdce5211a9@zimbra.network1.net> In-Reply-To: <4F57B476.1000808@KingsMountain.com> Content-Type: multipart/alternative; boundary="=_cbedae8b-f1d9-4611-a1bc-edc654f904f3" MIME-Version: 1.0 X-Originating-IP: [24.31.168.213] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:24:05 -0000 --=_cbedae8b-f1d9-4611-a1bc-edc654f904f3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit What is(are) the "captive portal" issue(s) and how does this address it? Just curious... ----- Original Message ----- > From: "=JeffH" > To: dhcwg@ietf.org > Cc: "Julian Reschke" , "Mark Nottingham" > > Sent: Wednesday, March 7, 2012 2:18:14 PM > Subject: [dhcwg] "captive portal" issues addressed ? > ..which seems to me to address (if deployed in hotspots and clients) > the > "captive portal" issue. --=_cbedae8b-f1d9-4611-a1bc-edc654f904f3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>What is(are) the "captive portal" issue(s) and how does this address it?<= /div>
Just curious...

From: "=3DJeffH= " <Jeff.Hodges@KingsMountain.com>
To: dhcwg@ietf.org
= Cc: "Julian Reschke" <julian.reschke@gmx.de>, "Mark Nottingham" &= lt;mnot@mnot.net>
Sent: Wednesday, March 7, 2012 2:18:14 PMSubject: [dhcwg] "captive portal" issues addressed ?


..w= hich seems to me to address (if deployed in hotspots and clients) the
"= captive portal" issue.

--=_cbedae8b-f1d9-4611-a1bc-edc654f904f3-- From linux@thehobsons.co.uk Wed Mar 7 14:00:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A9D11E80BB for ; Wed, 7 Mar 2012 14:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WuK2RdfMLTk for ; Wed, 7 Mar 2012 14:00:16 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id B92BE11E80AF for ; Wed, 7 Mar 2012 14:00:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 8B20D10401A for ; Wed, 7 Mar 2012 22:00:08 +0000 (GMT) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJiebwhCrf3H for ; Wed, 7 Mar 2012 22:00:08 +0000 (GMT) Received: from simon.thehobsons.co.uk (simons-macbookpro.thehobsons.co.uk [192.168.0.202]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 29D1429EDB for ; Wed, 7 Mar 2012 22:00:08 +0000 (GMT) Mime-Version: 1.0 Message-Id: In-Reply-To: <72ca9fbb-5721-466d-976d-0cbdce5211a9@zimbra.network1.net> References: <72ca9fbb-5721-466d-976d-0cbdce5211a9@zimbra.network1.net> Date: Wed, 7 Mar 2012 21:59:03 +0000 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:00:18 -0000 perl-list wrote: >What is(are) the "captive portal" issue(s) and how does this address it? Wifi hotspot experience today ... Your device connects to a wireless network and "nothing works". You have to open up a web browser, attempt to connect to any random web page, and the hotspot controller will intercept your request and serve you up the captive portal login page. Only when you've logged in (with a different username/password and user experience for each different provider) will your internet connection work properly. IIRC, having read about this a little while ago, the proposals are for some common standards etc that would allow the client to automatically authenticate with any hotspot you have permission to use (ie any of those your service provider has a commercial agreement with). Thus you get the "cellular experience" where you don't have any concept of which base station your device is working through, only that "it works" whenever you are in range of any base station your provider operates (or is operated by another provider your own provider has an agreement with). -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From Basavaraj.Patil@nokia.com Wed Mar 7 14:14:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE50311E80B8 for ; Wed, 7 Mar 2012 14:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.048 X-Spam-Level: X-Spam-Status: No, score=-105.048 tagged_above=-999 required=5 tests=[AWL=1.551, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNANcW5lEZWz for ; Wed, 7 Mar 2012 14:14:41 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id C73AC11E80AF for ; Wed, 7 Mar 2012 14:14:40 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q27MEcha001052; Thu, 8 Mar 2012 00:14:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 00:14:37 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Wed, 7 Mar 2012 23:14:37 +0100 From: To: , Thread-Topic: [dhcwg] "captive portal" issues addressed ? Thread-Index: AQHM/JcVLy8YEISgWk2jDBGhUb3j3pZfNoeAgAAai4D//5/GAA== Date: Wed, 7 Mar 2012 22:14:36 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <7785E6612A2AC349962DC4AA9CC1D40C@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Mar 2012 22:14:37.0490 (UTC) FILETIME=[AF264920:01CCFCAF] X-Nokia-AV: Clean Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:14:41 -0000 On 3/7/12 3:59 PM, "ext Simon Hobson" wrote: >perl-list wrote: >>What is(are) the "captive portal" issue(s) and how does this address it? > >Wifi hotspot experience today ... >Your device connects to a wireless network and "nothing works". You >have to open up a web browser, attempt to connect to any random web >page, and the hotspot controller will intercept your request and >serve you up the captive portal login page. Only when you've logged >in (with a different username/password and user experience for each >different provider) will your internet connection work properly. > >IIRC, having read about this a little while ago, the proposals are >for some common standards etc that would allow the client to >automatically authenticate with any hotspot you have permission to >use (ie any of those your service provider has a commercial agreement >with). Thus you get the "cellular experience" where you don't have >any concept of which base station your device is working through, >only that "it works" whenever you are in range of any base station >your provider operates (or is operated by another provider your own >provider has an agreement with). The proposed standards for "cellular experience" is Hotspot 2.0 which is now being done in Wifi alliance (WFA). > >--=20 >Simon Hobson > >Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed >author Gladys Hobson. Novels - poetry - short stories - ideal as >Christmas stocking fillers. Some available as e-books. >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From Jeff.Hodges@KingsMountain.com Wed Mar 7 14:17:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCBD11E80AF for ; Wed, 7 Mar 2012 14:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.873 X-Spam-Level: X-Spam-Status: No, score=-99.873 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8FL4gw3uqio for ; Wed, 7 Mar 2012 14:17:10 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 0E50811E8074 for ; Wed, 7 Mar 2012 14:17:09 -0800 (PST) Received: (qmail 15420 invoked by uid 0); 7 Mar 2012 22:17:09 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 7 Mar 2012 22:17:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=dI+hYYUTEyCS54oK/ASJ5lJbQBavxI4+lvuBn1sKGmc=; b=2MeD3Adr+xWyTtyQkx0QNpHQFp3AT9LeUfNv2ncFWXdIT439zyrTa5tbPS8pEDCPEO3sKZkCCB97MguJZM4hgJfoDh4+UThz7+H2sWXFhYujqiseJKtKKnB1A8wHY0PV; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S5PAS-0005sf-Uv for dhcwg@ietf.org; Wed, 07 Mar 2012 15:17:09 -0700 Message-ID: <4F57DE62.2010305@KingsMountain.com> Date: Wed, 07 Mar 2012 14:17:06 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:17:11 -0000 > What is(are) the "captive portal" issue(s) and how does this address i= t? from [0] .. "The captive portal technique forces an HTTP client on a network to se= e a=20 special web page (usually for authentication purposes) before using the=20 Internet normally. A captive portal turns a Web browser into an authentic= ation=20 device.[1] This is done by intercepting all packets, regardless of addres= s or=20 port, until the user opens a browser and tries to access the Internet. At= that=20 time the browser is redirected to a web page which may require authentica= tion=20 and/or payment, or simply display an acceptable use policy and require th= e user=20 to agree. Captive portals are used at many Wi-Fi hotspots, and can be use= d to=20 control wired access (e.g. apartment houses, hotel rooms, business center= s,=20 "open" Ethernet jacks) as well." The wikipedia article lists some of the more common approaches, as well a= s=20 outlines limitations. The main issue is that "There is more than one way to implement a captive= =20 portal." Thus they all end up working a bit differently, and there's als= o=20 conflicts with end-to-end security such as HTTP Strict Transport Security= =20 (HSTS), e.g. if one's browser will only use TLS/SSL to contact some websi= te you=20 use to attempt to get the captive portal page to load in your browser, bu= t the=20 captive portal you're behind doesn't use TLS, and doesn't pass it through= , you=20 end up just sitting there with a hung browser, unless you think of some o= ther=20 website to try to contact that is not HTTPS-only. There's been various modest attempts in the IETF to standardize something= that=20 addresses captive portals, e.g. draft-nottingham-http-portal-02 [1], supe= rseded=20 by section 6.1 "The 511 Status Code and Captive Portals" of=20 draft-nottingham-http-new-status-04 [2]. Then there's also the Microsoft Windows use of DHCP option 252 [3] in "We= b=20 Proxy Autodiscovery Protocol (WPAD)", which is not fully standardized, an= d has=20 some spotty coverage (outside of the Microsoft world), AFAICT [4, 5]. WPA= D was=20 a work item of the WREC (Web Replication and Caching) working group (WG),= which=20 morphed into the WEBI (Web Intermediaries) WG. The two serial WG's produc= ed two=20 "Informational" RFCs before disbanding [6, 7], as well as this I-D [8] (= I=20 haven't reviewed all of them in detail, tho they don't mention the term=20 "captive portal"). HTH, =3DJeffH [0] Captive portal https://en.wikipedia.org/wiki/Captive_portal [1] The Network Authentication Required HTTP Status Code https://tools.ietf.org/html/draft-nottingham-http-portal [2] Additional HTTP Status Codes https://tools.ietf.org/html/draft-nottingham-http-new-status [3] Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BO= OTP)=20 Parameters =20 http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-paramete= rs.xml [4] Web Proxy Autodiscovery Protocol (WPAD) https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol [5] RE: Auto-detect in Firefox with a wpad file??? - 15.Apr.2009 6:27:28 = AM http://forums.isaserver.org/fb.aspx?m=3D2002085031 Better Proxy Settings=85 Bluecoat, wpad, proxy.pac & dhcp option 252= =20 http://www.linickx.com/960/better-proxy-settings-bluecoat-wpad-proxypac-d= hcp-option-252 DHCP, 'wpad' option 252 (Apple Support Communities) https://discussions.apple.com/thread/2309560?start=3D0&tstart=3D0 Microsoft Internet Security and Acceleration Server 2004 Automatic Discovery for Firewall and Web Proxy Clients http://technet.microsoft.com/en-us/library/cc713344.aspx [6] Internet Web Replication and Caching Taxonomy https://tools.ietf.org/html/rfc3040 [7] Known HTTP Proxy/Caching Problems https://tools.ietf.org/html/rfc3143 [8] Known HTTP Proxy/Caching Problems https://tools.ietf.org/id/draft-ietf-wrec-known-prob-03.txt --- end From Ted.Lemon@nominum.com Wed Mar 7 14:37:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CA511E80BC for ; Wed, 7 Mar 2012 14:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk5722JRGu0v for ; Wed, 7 Mar 2012 14:37:15 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id C7C5011E8074 for ; Wed, 7 Mar 2012 14:37:14 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT1fjGrJuEXm9CPv289vxvNuQ9A6Q4rnV@postini.com; Wed, 07 Mar 2012 14:37:14 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B22EE1B8553 for ; Wed, 7 Mar 2012 14:37:13 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A6D4619005C; Wed, 7 Mar 2012 14:37:13 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 7 Mar 2012 14:37:13 -0800 From: Ted Lemon To: =JeffH Thread-Topic: [dhcwg] "captive portal" issues addressed ? Thread-Index: AQHM/JcTxZjI1fkCkUeA5uz7r/dl6pZf8pmA Date: Wed, 7 Mar 2012 22:37:13 +0000 Message-ID: References: <4F57B476.1000808@KingsMountain.com> In-Reply-To: <4F57B476.1000808@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3D5DFC698FC4054C98D25ECCFDC1CA4E@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "" , Mark Nottingham Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:37:15 -0000 What they're talking about here seems not to be related to captive portals = per se, but rather to captive customers. As an end user, this sounds like a= really bad idea. I'm sure there's a ton of money in it. Why on earth would I want every WiFi hotspot in the world to be able to imm= ediately identify who I am, before I even agree to connect? From dankney@network1.net Wed Mar 7 17:02:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECA421E800C for ; Wed, 7 Mar 2012 17:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtAnDVLsQ5hT for ; Wed, 7 Mar 2012 17:02:27 -0800 (PST) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7398221E8011 for ; Wed, 7 Mar 2012 17:02:27 -0800 (PST) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 5FF0754281B for ; Wed, 7 Mar 2012 20:02:26 -0500 (EST) Date: Wed, 07 Mar 2012 20:02:26 -0500 (EST) From: perl-list To: dhcwg Message-ID: <9d2ff530-6fa1-4453-892b-0eec73d395af@zimbra.network1.net> In-Reply-To: Content-Type: multipart/alternative; boundary="=_63365ba8-4348-4f02-bf1d-b4ea4b5b79d3" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:02:28 -0000 --=_63365ba8-4348-4f02-bf1d-b4ea4b5b79d3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Agreed. I was just wondering what the issue surrounding a captive portal was. Windows, for example, even detects that you need to authenticate and pops a bubble down by the clock prompting you to do so. With the continued expansion of the web browser as the portal of nearly everything internet for many people, I would suspect that people will have less and less of this captive portal issue. btw, does this actually have anything to do with DHCP, or is this just off topic? ----- Original Message ----- > From: "Ted Lemon" > To: "=JeffH" > Cc: "Julian Reschke" , "" > , "Mark Nottingham" > Sent: Wednesday, March 7, 2012 5:37:13 PM > Subject: Re: [dhcwg] "captive portal" issues addressed ? > What they're talking about here seems not to be related to captive > portals per se, but rather to captive customers. As an end user, > this sounds like a really bad idea. I'm sure there's a ton of money > in it. > Why on earth would I want every WiFi hotspot in the world to be able > to immediately identify who I am, before I even agree to connect? > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=_63365ba8-4348-4f02-bf1d-b4ea4b5b79d3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>Agr= eed.  I was just wondering what the issue surrounding a captive portal= was.  Windows, for example, even detects that you need to authenticat= e and pops a bubble down by the clock prompting you to do so.

With the continued expansion of the web browser as the portal of near= ly everything internet for many people, I would suspect that people will ha= ve less and less of this captive portal issue.

btw= , does this actually have anything to do with DHCP, or is this just off top= ic?


From: "Ted Lemon" <Ted.L= emon@nominum.com>
To: "=3DJeffH" <Jeff.Hodges@KingsMountain= .com>
Cc: "Julian Reschke" <julian.reschke@gmx.de>, "<= ;dhcwg@ietf.org>" <dhcwg@ietf.org>, "Mark Nottingham" <mnot@mno= t.net>
Sent: Wednesday, March 7, 2012 5:37:13 PM
Subject= : Re: [dhcwg] "captive portal" issues addressed ?

What they're t= alking about here seems not to be related to captive portals per se, but ra= ther to captive customers. As an end user, this sounds like a really bad id= ea.   I'm sure there's a ton of money in it.

Why on earth would= I want every WiFi hotspot in the world to be able to immediately identify = who I am, before I even agree to connect?

__________________________= _____________________
dhcwg mailing list
dhcwg@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dhcwg


--=_63365ba8-4348-4f02-bf1d-b4ea4b5b79d3-- From Ted.Lemon@nominum.com Wed Mar 7 18:50:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ECA21F853E for ; Wed, 7 Mar 2012 18:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WZApmHIs+A3 for ; Wed, 7 Mar 2012 18:50:23 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 497E121F8539 for ; Wed, 7 Mar 2012 18:50:22 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT1gebRxgpFkkuCfgjdq1wCUvB/xy9jsY@postini.com; Wed, 07 Mar 2012 18:50:22 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 16EC31B8311 for ; Wed, 7 Mar 2012 18:50:21 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0EAA019005C; Wed, 7 Mar 2012 18:50:21 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 7 Mar 2012 18:50:20 -0800 From: Ted Lemon To: perl-list Thread-Topic: [dhcwg] "captive portal" issues addressed ? Thread-Index: AQHM/JcTxZjI1fkCkUeA5uz7r/dl6pZf8pmAgAAolgCAAB4kgA== Date: Thu, 8 Mar 2012 02:50:20 +0000 Message-ID: <6C12D97C-EE31-4331-B868-068681C68ADF@nominum.com> References: <9d2ff530-6fa1-4453-892b-0eec73d395af@zimbra.network1.net> In-Reply-To: <9d2ff530-6fa1-4453-892b-0eec73d395af@zimbra.network1.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_6C12D97CEE314331B868068681C68ADFnominumcom_" MIME-Version: 1.0 Cc: dhcwg Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:50:25 -0000 --_000_6C12D97CEE314331B868068681C68ADFnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 7, 2012, at 8:02 PM, perl-list > wrote: Agreed. I was just wondering what the issue surrounding a captive portal w= as. Windows, for example, even detects that you need to authenticate and p= ops a bubble down by the clock prompting you to do so. Mac does too, as does iOS. Not sure about Android. With the continued expansion of the web browser as the portal of nearly eve= rything internet for many people, I would suspect that people will have les= s and less of this captive portal issue. Yes, it's essentially a solved problem. btw, does this actually have anything to do with DHCP, or is this just off = topic? It did back when we needed to solve the captive portal problem using DHCP a= uthentication of some sort. However, at this point the two issues have, a= s you suggest, essentially become orthogonal. I think there's still a use= for DHCP authentication, but now it's for replacing PPPoE, rather than for= replacing captive portals. --_000_6C12D97CEE314331B868068681C68ADFnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 7, 2012, at 8:02 PM, perl-list <perl-list@network1.net>
 wrote:
Agreed.  I was just wondering what the issue surrounding a captive portal was= .  Windows, for example, even detects that you need to authenticate an= d pops a bubble down by the clock prompting you to do so.

Mac does too, as does iOS.   Not sure about Android.

With the continued expansion of the web browser as the portal of nearly eve= rything internet for many people, I would suspect that people will have les= s and less of this captive portal issue.

Yes, it's essentially a solved problem.

btw, does this actually have anything to do with DHCP, or is this just off = topic?

It did back when we needed to solve the captive portal problem using D= HCP authentication of some sort.   However, at this point the two issu= es have, as you suggest, essentially become orthogonal.   I think ther= e's still a use for DHCP authentication, but now it's for replacing PPPoE, rather than for replacing captive portals.

--_000_6C12D97CEE314331B868068681C68ADFnominumcom_-- From jiangsheng@huawei.com Wed Mar 7 19:41:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAB021F8522 for ; Wed, 7 Mar 2012 19:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9d4gnpA-QXe for ; Wed, 7 Mar 2012 19:41:54 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A521F851B for ; Wed, 7 Mar 2012 19:41:19 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J006NKRKKOQ@szxga05-in.huawei.com> for dhcwg@ietf.org; Thu, 08 Mar 2012 11:41:09 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J001WGRKJMW@szxga05-in.huawei.com> for dhcwg@ietf.org; Thu, 08 Mar 2012 11:41:08 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHR09548; Thu, 08 Mar 2012 11:40:37 +0800 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 11:39:56 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.83]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 11:40:34 +0800 Date: Thu, 08 Mar 2012 03:40:34 +0000 From: Sheng Jiang In-reply-to: X-Originating-IP: [10.108.4.88] To: Thomas Huth , "dhcwg@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B92190644A4@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt Thread-index: AQHM/BQ4pIFCNgzx5kC21OkbPiLLJZZeCZKAgACISiA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120307033858.24455.93295.idtracker@ietfa.amsl.com> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 03:41:55 -0000 Hi, Thomas, Thank you for your review and comments. They will be integrated into new version. A couple of explanation in lines. Best regards, Sheng > -----Original Message----- > From: Thomas Huth [mailto:THUTH@de.ibm.com] > Sent: Wednesday, March 07, 2012 5:23 PM > To: dhcwg@ietf.org > Cc: Sheng Jiang; shenshuo@cnnic.cn > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt > > Hi, > > I quickly read through your draft, I like the idea, but I also have > some > remarks / questions: > > Section 1. : > > "... thus the address of a DHCPv6 message sender, which can be > a DHCPv6 server, a relay agent or a client, is able to be verified by > a receiver." > > I'd suggest to replace "is able to be verified" with "can be > verified". > > > Section 4.: > > You've got a very long quote from RFC3972 here: "CGAs are IPv6 > addresses > ..." > I think you don't have to do that. If somebody does not know RFC3972 > yet, > he or she can read that RFC, so no need to bloat your draft by > repeating > this here. > > > "It assumes the secured DHCPv6 message sender has already haven CGAs" > What do you mean by "haven" CGAs here? > "and the receiver has already been given the CGAs of the sender." > > How could that have happened? By out-of-band, manual configuration > again? Yes, out of band, manual configuration or saved from preview communication, etc. > "can verify both the CGA and signature, then process the payload of > the DHCPv6 message only if the validation is successful. " > > That part of the sentence is repeated twice, on page 4 and 5 > > > Section 5.2: > > Why do you need a "Padding" field in this option? AFAIK according to > RFC > 3315 there should not be any padding between the options. This padding is only needed if the length of signature is not an multiple of 8 bits. It's an internal padding rather than padding between the options. Best regards, Sheng > > Regards, > T. Huth > > > dhcwg-bounces@ietf.org wrote on 07.03.2012 04:38:58: > > > 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 : Secure DHCPv6 Using CGAs > > Author(s) : Sheng Jiang > > Sean Shen > > Filename : draft-ietf-dhc-secure-dhcpv6-05.txt > > Pages : 15 > > Date : 2012-03-06 > > > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables > > DHCPv6 servers to pass configuration parameters. It offers > > configuration flexibility. If not secured, DHCPv6 is vulnerable to > > various attacks, particularly spoofing attack. This document > analyzes > > the security issues of DHCPv6 and specifies a Secure DHCPv6 > mechanism > > based on using CGAs. From maxpassion@gmail.com Wed Mar 7 19:45:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E96521E8012 for ; Wed, 7 Mar 2012 19:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHKFSN1gP38v for ; Wed, 7 Mar 2012 19:45:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6466521E800E for ; Wed, 7 Mar 2012 19:45:30 -0800 (PST) Received: by iazz13 with SMTP id z13so108094iaz.31 for ; Wed, 07 Mar 2012 19:45:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=65Qu+dkMZJhDvkuCAsR79oXkMlHFPaE5RdGvsEJ+N1k=; b=dqCf7UhlLr0AUCBOXVxRszqrg0A3lD/+Uh523L07WJ6KmIttC/wUsjQerhE/sN8DSD UsbsqQq7pC1PYBfWW+OHEWiiOUzLwVRmtJQplgwS+rHfU7aoktFsl6lGDCrKY7Q4ijf1 uQKpUz5HbPZqQ8HjKJViWbuv7APpArOX1Mic/ZVsqwDQqwU8DWvL9A+ACRuebosQ0ZAa PH5YrGFmhWDTgzkNa97YQwu0HFQSDJ+Vfs2Qsge3BXI+w0yAPs7cjwFzue7g92DlxeuV bFItIPLUs8Dk4OXL/sGiSeLIN5lx9LMd8R9sIWbQtu3lDeTJBy/MVtDXH9D38GkDhKW0 hk2w== MIME-Version: 1.0 Received: by 10.50.179.98 with SMTP id df2mr4135608igc.32.1331178329933; Wed, 07 Mar 2012 19:45:29 -0800 (PST) Received: by 10.42.244.138 with HTTP; Wed, 7 Mar 2012 19:45:29 -0800 (PST) In-Reply-To: <4F57DE62.2010305@KingsMountain.com> References: <4F57DE62.2010305@KingsMountain.com> Date: Thu, 8 Mar 2012 11:45:29 +0800 Message-ID: From: liu dapeng To: "=JeffH" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 03:45:31 -0000 2012/3/8, =3DJeffH : > > What is(are) the "captive portal" issue(s) and how does this address i= t? > > from [0] .. > > "The captive portal technique forces an HTTP client on a network to se= e a > special web page (usually for authentication purposes) before using the > Internet normally. A captive portal turns a Web browser into an > authentication > device.[1] This is done by intercepting all packets, regardless of addres= s > or > port, until the user opens a browser and tries to access the Internet. At > that > time the browser is redirected to a web page which may require > authentication > and/or payment, or simply display an acceptable use policy and require th= e > user > to agree. Captive portals are used at many Wi-Fi hotspots, and can be use= d > to > control wired access (e.g. apartment houses, hotel rooms, business center= s, > "open" Ethernet jacks) as well." > > The wikipedia article lists some of the more common approaches, as well a= s > outlines limitations. > > The main issue is that "There is more than one way to implement a captive > portal." Thus they all end up working a bit differently, and there's als= o > conflicts with end-to-end security such as HTTP Strict Transport Security You can refer WISPr for web portal based authentication: http://en.wikipedia.org/wiki/WISPr Regards, -Dapeng Liu > (HSTS), e.g. if one's browser will only use TLS/SSL to contact some websi= te you > use to attempt to get the captive portal page to load in your browser, bu= t > the > captive portal you're behind doesn't use TLS, and doesn't pass it through= , > you > end up just sitting there with a hung browser, unless you think of some > other > website to try to contact that is not HTTPS-only. > > There's been various modest attempts in the IETF to standardize something > that > addresses captive portals, e.g. draft-nottingham-http-portal-02 [1], > superseded > by section 6.1 "The 511 Status Code and Captive Portals" of > draft-nottingham-http-new-status-04 [2]. > > Then there's also the Microsoft Windows use of DHCP option 252 [3] in "We= b > Proxy Autodiscovery Protocol (WPAD)", which is not fully standardized, an= d > has > some spotty coverage (outside of the Microsoft world), AFAICT [4, 5]. WPA= D > was > a work item of the WREC (Web Replication and Caching) working group (WG), > which > morphed into the WEBI (Web Intermediaries) WG. The two serial WG's produc= ed > two > "Informational" RFCs before disbanding [6, 7], as well as this I-D [8] (= I > haven't reviewed all of them in detail, tho they don't mention the term > "captive portal"). > > HTH, > > =3DJeffH > > > [0] Captive portal > https://en.wikipedia.org/wiki/Captive_portal > > [1] The Network Authentication Required HTTP Status Code > https://tools.ietf.org/html/draft-nottingham-http-portal > > [2] Additional HTTP Status Codes > https://tools.ietf.org/html/draft-nottingham-http-new-status > > [3] Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol > (BOOTP) > Parameters > > http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-paramete= rs.xml > > [4] Web Proxy Autodiscovery Protocol (WPAD) > https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol > > [5] RE: Auto-detect in Firefox with a wpad file??? - 15.Apr.2009 6:27:28 = AM > http://forums.isaserver.org/fb.aspx?m=3D2002085031 > > Better Proxy Settings=85 Bluecoat, wpad, proxy.pac & dhcp option 252 > > http://www.linickx.com/960/better-proxy-settings-bluecoat-wpad-proxypac-d= hcp-option-252 > > DHCP, 'wpad' option 252 (Apple Support Communities) > https://discussions.apple.com/thread/2309560?start=3D0&tstart=3D0 > > Microsoft Internet Security and Acceleration Server 2004 > Automatic Discovery for Firewall and Web Proxy Clients > http://technet.microsoft.com/en-us/library/cc713344.aspx > > > [6] Internet Web Replication and Caching Taxonomy > https://tools.ietf.org/html/rfc3040 > > [7] Known HTTP Proxy/Caching Problems > https://tools.ietf.org/html/rfc3143 > > [8] Known HTTP Proxy/Caching Problems > https://tools.ietf.org/id/draft-ietf-wrec-known-prob-03.txt > > --- > end > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --=20 ------ Best Regards, Dapeng Liu From dankney@network1.net Thu Mar 8 05:36:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3963C21F8592 for ; Thu, 8 Mar 2012 05:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBSbmj4QxaeO for ; Thu, 8 Mar 2012 05:36:33 -0800 (PST) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42121F8557 for ; Thu, 8 Mar 2012 05:36:31 -0800 (PST) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id D3EEB5427EE for ; Thu, 8 Mar 2012 08:36:30 -0500 (EST) Date: Thu, 08 Mar 2012 08:36:30 -0500 (EST) From: perl-list To: dhcwg Message-ID: In-Reply-To: <6C12D97C-EE31-4331-B868-068681C68ADF@nominum.com> Content-Type: multipart/alternative; boundary="=_b41e6740-d30f-40a8-ba09-6f858221d520" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Subject: Re: [dhcwg] "captive portal" issues addressed ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:36:34 -0000 --=_b41e6740-d30f-40a8-ba09-6f858221d520 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Ted Lemon" > To: "perl-list" > Cc: "dhcwg" > Sent: Wednesday, March 7, 2012 9:50:20 PM > Subject: Re: [dhcwg] "captive portal" issues addressed ? > It did back when we needed to solve the captive portal problem using > DHCP authentication of some sort. However, at this point the two > issues have, as you suggest, essentially become orthogonal. I think > there's still a use for DHCP authentication, but now it's for > replacing PPPoE, rather than for replacing captive portals. Agree with replacing PPPoE. DHCP authentication would be quite interesting in the environment at the company I work for. --=_b41e6740-d30f-40a8-ba09-6f858221d520 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

From: "Ted Lemon" <Ted.Lemon@nominum.com>
To: "perl-list" <perl-list@network1.net>
Cc: "dhcwg" <dhcwg@ietf.org>
Sent: Wednesday, March 7, 2012 9:50:20 PM
Subject: Re: [dhcwg] "captive portal" issues addressed ?


It did back when we needed to solve the captive portal problem using DHCP authentication of some sort.   However, at this point the two issues have, as you suggest, essentially become orthogonal.   I think there's still a use for DHCP authentication, but now it's for replacing PPPoE, rather than for replacing captive portals.

Agree with replacing PPPoE.  DHCP authentication would be quite interesting in the environment at the company I work for.
--=_b41e6740-d30f-40a8-ba09-6f858221d520-- From david.schumacher@alcatel-lucent.com Thu Mar 8 13:16:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E4E21E8048 for ; Thu, 8 Mar 2012 13:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-YXZZ-WbTR4 for ; Thu, 8 Mar 2012 13:16:38 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8921E8039 for ; Thu, 8 Mar 2012 13:16:37 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q28LGYfA011377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Mar 2012 15:16:34 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q28LGRXe003925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 8 Mar 2012 15:16:34 -0600 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 8 Mar 2012 15:16:32 -0600 From: "Schumacher, David K (David)" To: "dhcwg@ietf.org" Date: Thu, 8 Mar 2012 15:16:46 -0600 Thread-Topic: Re: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt Thread-Index: Acz9cMTibh+gHHOIQSa3VEyr/8B8NA== Message-ID: <73893B87393E3945A80108B70FC12A211364699084@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 X-Mailman-Approved-At: Thu, 08 Mar 2012 13:32:05 -0800 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 21:18:19 -0000 I have one minor comment on the subject draft: The proposed DUID-SA format in Section 5.3 of the draft violates the length= restriction of DUID contents, as defined in RFC 3315, Section 9.1, which s= tates that the DUID can be no more than 128 octets long (not included the t= ype code). Removing the 16-bit reserved field from the proposed format will bring the = definition into compliance.=20 Regards, D. Schumacher From jiangsheng@huawei.com Thu Mar 8 17:28:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73DB11E8074 for ; Thu, 8 Mar 2012 17:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGM1wzfrd1LB for ; Thu, 8 Mar 2012 17:28:44 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1902E11E8072 for ; Thu, 8 Mar 2012 17:28:44 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0L001OPG3P96@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 09 Mar 2012 09:28:37 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0L00H2RG3PKW@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 09 Mar 2012 09:28:37 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHI53689; Fri, 09 Mar 2012 09:28:37 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 09 Mar 2012 09:28:16 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.83]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 09 Mar 2012 09:28:32 +0800 Date: Fri, 09 Mar 2012 01:28:31 +0000 From: Sheng Jiang In-reply-to: <73893B87393E3945A80108B70FC12A211364699084@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> X-Originating-IP: [10.108.4.88] To: "Schumacher, David K (David)" , "dhcwg@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B9219065E4B@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Re: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt Thread-index: Acz9cMTibh+gHHOIQSa3VEyr/8B8NAAItysw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <73893B87393E3945A80108B70FC12A211364699084@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 01:28:44 -0000 Hi, David, Thanks for your comment. It is actual a mistake from us. I will address this with a new update by next Monday along with comments from Thomas. Many thanks and best regards, Sheng > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Schumacher, David K (David) > Sent: Friday, March 09, 2012 5:17 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-05.txt > > I have one minor comment on the subject draft: > > The proposed DUID-SA format in Section 5.3 of the draft violates the > length restriction of DUID contents, as defined in RFC 3315, Section > 9.1, which states that the DUID can be no more than 128 octets long > (not included the type code). > > Removing the 16-bit reserved field from the proposed format will bring > the definition into compliance. > > Regards, > > D. Schumacher > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Thu Mar 8 18:57:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C336721F8535 for ; Thu, 8 Mar 2012 18:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5pcfQeNrpWB for ; Thu, 8 Mar 2012 18:57:10 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2621F8534 for ; Thu, 8 Mar 2012 18:57:09 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT1lxhWXHi3F5uyuvsiL5Kvlocl+hwgLI@postini.com; Thu, 08 Mar 2012 18:57:10 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EFCE11B82ED for ; Thu, 8 Mar 2012 18:57:08 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E5E6019005C; Thu, 8 Mar 2012 18:57:08 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 8 Mar 2012 18:57:09 -0800 From: Ted Lemon To: dhcwg WG Thread-Topic: WGLC on draft-6man-addr-select-opt-03.txt Thread-Index: AQHM/aBQDi5W//M73kCJvZ280SChFg== Date: Fri, 9 Mar 2012 02:57:08 +0000 Message-ID: <80EADC80-84E0-42D1-8F26-A39A61F27C25@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0CE1DCD722BC5840859EDB24ABB3512B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC on draft-6man-addr-select-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 02:57:10 -0000 The authors of this document have requested a formal last call for it in th= e DHC working group, owing to the fact that it defines a DHCP option. Cou= ld folks please read the document and make sure that the DHCP bits are corr= ect? There is no need to say that you support or do not support the docum= ent, since it is not a DHC working group document=97the purpose of this las= t call is to get as much review by DHCP experts as possible. The last call will finish on March 22, 2012. Thanks! From internet-drafts@ietf.org Fri Mar 9 03:08:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2D121F862A; Fri, 9 Mar 2012 03:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9amCZ-s2mUrh; Fri, 9 Mar 2012 03:08:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFB421F85C2; Fri, 9 Mar 2012 03:08:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309110840.31527.30774.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 03:08:40 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 11:08:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Forcerenew Nonce Authentication Author(s) : David Miles Wojciech Dec James Bristow Roberta Maglione Filename : draft-ietf-dhc-forcerenew-nonce-05.txt Pages : 12 Date : 2012-03-09 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-05.txt From pengwu.thu@gmail.com Fri Mar 9 00:23:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A4021F8668 for ; Fri, 9 Mar 2012 00:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvEjnpfbhjcf for ; Fri, 9 Mar 2012 00:23:29 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE5F21F8664 for ; Fri, 9 Mar 2012 00:23:29 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so2521334pbb.31 for ; Fri, 09 Mar 2012 00:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YqMEWlEx5WbBpoXMDJUD9z3yCn9bJyHAKDRCRT7ohFw=; b=RFg5TE51BEvG8gh1VbKMlJK47JHLcQsW8+PY5nhTXxSloVUCpPkeXFyCIQZJzN2XvF PHZhEDJGBiXv421+T5ySbKQ7Wt5wf/eF+abO6RdkgfB/x52+du3vrRF35JCrlE1HqQmV YTp65FNTkKT7maS2BsYZBCkOIi1jOB+LJHTrc/Yy/vi5EMUQH8xxNSknZUbvEfq7gLIp 07l7woWFk5l1XJdofHE5BskipPtJLfg4v3hs3BLxuLyp76W4NPRIbuPq2HsKWQHKOa0Z JQm5xnvjQ2bEXEb1Kk6zyPXTY95zhUlcb1kKXsVLE5vKZs+lZJOIBaiIncoo91McH97+ UKoA== MIME-Version: 1.0 Received: by 10.68.220.129 with SMTP id pw1mr459623pbc.27.1331281409221; Fri, 09 Mar 2012 00:23:29 -0800 (PST) Received: by 10.68.130.197 with HTTP; Fri, 9 Mar 2012 00:23:29 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Mar 2012 16:23:29 +0800 Message-ID: From: Peng Wu To: dhcwg@ietf.org, tomasz.mrugalski@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 09 Mar 2012 08:16:49 -0800 Cc: sunqibupt@gmail.com Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 08:23:30 -0000 Hi Tomek, Sorry for my late reply. Thanks for your valuable comments. See inlines. > ------------------=A0Original=A0------------------ > From: =A0"Tomek Mrugalski"; > Date: =A0Fri, Feb 24, 2012 03:34 AM > To: =A0"dhcwg@ietf.org WG"; > Subject: =A0[dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-00 comments > > Hi, > I just read this draft and have several comments. I have mixed feelings > for such mechanisms, but I suppose that is a necessary evil. For that > reason I support this draft. Thanks for your support:) > > Current version of this draft omits one case that is quite important > IMHO. What if I can't modify my host, e.g. because it is a device (like > aforementioned blu-ray player or something much more costly, like > dedicated machines e.g. high performance printers) that does not allow > running third party software or its vendor is unable/unwilling to > provide such update? Yes. This case is not coverd by the current draft. However, my question her= e is, will it be necessary? The draft is generally used to allocate IPv4 address over IPv6 network. The host applying this mechanism uses this IPv4 address in IPv6 environment for certain purpose, for example, use it as the IPv4-over-IPv6 tunnel addre= ss. Now for a blu-ray player or a printer, it usually locate in a home network. Even if it support IPv6 beside IPv4, I don't see the purpose to drive it to acquire IPv4 address from a remote server through IPv6. > > Why CRA must be placed on the same host as client? CRA could be anywhere > on the same link as hosts, right? Also, it can be shared between many > clients. These are my assumptions. If they are true, something to that > effect should be added to the text. Yes. Theoretically CRA can be on the same link as hosts. Then it looks very much like an actual normal DHCP relay, except that the two side of the rela= y are in different address families. However, it'll quite broaden the picture. Originally we only want to design a mechanism to enable the DHCPv4 procedure between host and server/relay both in IPv6 network, CRA is used as a "virtual" concept. = You are suggesting the scenario like "host--IPv4(or dual-stack) LAN--CRA--IPv6 network--TRA/TSV". This is interesting, but again I guess we should consider the purpose/motivation, > > Section 6 mentions that CRA is being provisioned with TSV/TRA address. > Why CRA can't use normal DHCPv6 mechanism for that? I think it could use > server unicast, already defined option in DHCPv6. Dual-stack > (DHCPv4+DHCPv6) server could easily distinguish between regular DHCPv6 > traffic and DHCPv4-encapsulated-in-IPv6 traffic as they are sent to > different > ports. CRA need an IPv6 address, to be the destination of unicast DHCP messages, and CRA can't discover this address itself. The particularity in this case is that the communication could only be IPv6-unicast from the very begining. We could use a DHCPv6 option to deliver the information during DHCPv6 process for the host. But I'm not sure what you are suggesting here with se= rver unicast option and dual-stack server. Could you please be more specific? > > I would rename this 6ADDR to something else. Someone (who didn't read > the draft) could be mislead to think that this option allows you to > configure IPv6 address using DHCPv4. Indeed. We'll rename it. > > Have you considered other alternative: put whole DHCPv4 into DHCPv6 > option and then send it as DHCPv6 packet (possibly as relay-forw)? It > would have one mayor advantage of being able to reuse existing deployed > DHCPv6 relays. I haven't thought this through, so there may be pitfalls > here, but regular DHCPv6 relay is not supposed to inspect packet too > deeply (like dropping it because of missing client-id), so it may work. > On the other hand, that would work only for dual-stacked servers, so > its usability is somewhat limited. Yes, we considered that. I think the bottom line is we are still running DHCPv4, and we still need a DHCPv4 server rather than DHCPv6 server to process all the requests and options, so we stick to DHCPv4. Maybe Ted can help to explain better here:) > > My understanding is that server basically echoes 6ADDR option back, if > present. Does it differ in any way server normally processes Relay Agent > Information option, as defined in RFC3046? Something to that effect > should be added to Section 7. I think it should follow exactly what RFC3046 said. We'll put a sentence on this in the draft, for clarification. > > In section 8 (and many other sections) you state that packet is > forwarded to IPv6 address. Please clearly specify destination port > number. I assume it should be 67, but it is better to make is clear. > There should probably be a statement along the lines: "TRA SHOULD (or > even MUST) drop DHCPv4-over-IPv6 traffic that is not originated from > configured server address". Yes, we stated this in section 6. Seems it is not enough, ha. We'll emphasi= ze it more and also add the sentense you put here. > > Security considerations section should discuss cases, where TRA can be > exploited to forward traffic. It is probably of limited usefulness, but > still I think it could allow to attack IPv4 machines from IPv6 Internet. > If port restrictions are added as suggested, this potential attack > vector would be limited to DHCPv4 protocol only. Yes. We'll put the case of DHCP protocol attack. BTW, I guess it's no diffe= rent from the situation today except the attacker and the victim(could be the ho= st or the DHCP server) are in different address families, right? > > Security considerations should discuss that DHCPv4 traffic over IPv6 > will most likely bypass existing firewalls (that can filter DHCPv4 over > IPv4 and DHCPv6 over IPv6). Good point. We'll add this effect. > > Editorial comments: > Section 4, first paragraph: shoudl =3D> should > > Second paragraph: Discussion about applicability would be useful. What > if the host is a device that I cannot modify to run extra software? > > Paragraph above Fig. 2. > Since Option 82 doesn't has =3D> Since Option 82 doesn't have Thanks and sorry for that :--) > Hope that helps. > > Tomek > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Sat Mar 10 14:29:03 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3D21F84E2 for ; Sat, 10 Mar 2012 14:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.27 X-Spam-Level: X-Spam-Status: No, score=-105.27 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUBX2o-fx3i5 for ; Sat, 10 Mar 2012 14:29:03 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id ABBDC21F84B9 for ; Sat, 10 Mar 2012 14:29:02 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT1vVrqCcPiDsH39sw0I9Sdk8sLRcsZcA@postini.com; Sat, 10 Mar 2012 14:29:02 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 92E771B8480 for ; Sat, 10 Mar 2012 14:29:01 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 81CCA19005C; Sat, 10 Mar 2012 14:29:01 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Sat, 10 Mar 2012 14:28:55 -0800 From: Ted Lemon To: Bharat Joshi Thread-Topic: WGLC: draft-ietf-dhc-relay-id-suboption-09.txt Thread-Index: AQHM/w0tkeQuZjxVEUSrkbzqG08Zpw== Date: Sat, 10 Mar 2012 22:28:54 +0000 Message-ID: <67E4F90D-7743-45A5-8595-C82DE36EC0F9@nominum.com> References: <27E2BF10-7AEE-4B64-B04A-87708CB02C00@fugue.com> In-Reply-To: <27E2BF10-7AEE-4B64-B04A-87708CB02C00@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <8ED6633891DC3740A679D3BE3F492923@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ralph Droms Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-relay-id-suboption-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 22:29:03 -0000 On Dec 15, 2011, at 2:17 PM, Ted Lemon wrote: > I've read the draft and it looks reasonable, but I'd like to see more re= view, so I'm doing this last call in hopes that someone will take the time = to look at the document. Because of the Christmas and New Years' holidays= that some participants will be celebrating, we won't call consensus on thi= s until January 5. Looks like this one fell through the cracks. I issued a last call in Dece= mber, scheduled to do the consensus call on January 5. As is fairly commo= n (and perfectly fine) nobody responded until well after the deadline, at w= hich point we got one thorough review and a lot of support for the document= . So it passes last call, and hopefully the authors will reissue a new versio= n that contains any changes that were suggested and that the authors think = make sense. Bharat Joshi, since you asked for the last call and have been= doing updates, can you comment on whether you have updated the document to= address issues raised in last call? From internet-drafts@ietf.org Sun Mar 11 14:37:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3421F8757; Sun, 11 Mar 2012 14:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2kFCrMzpVxQ; Sun, 11 Mar 2012 14:37:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDDF21F8691; Sun, 11 Mar 2012 14:37:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120311213724.29310.52647.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 14:37:24 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 21:37:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Forcerenew Nonce Authentication Author(s) : David Miles Wojciech Dec James Bristow Roberta Maglione Filename : draft-ietf-dhc-forcerenew-nonce-06.txt Pages : 12 Date : 2012-03-11 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-06.txt From internet-drafts@ietf.org Mon Mar 12 00:34:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2ED21F8548; Mon, 12 Mar 2012 00:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2r-VBcdFDMQ; Mon, 12 Mar 2012 00:34:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F0821F84AF; Mon, 12 Mar 2012 00:34:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312073446.4004.38029.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 00:34:46 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 07:34:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Secure DHCPv6 Using CGAs Author(s) : Sheng Jiang Sean Shen Filename : draft-ietf-dhc-secure-dhcpv6-06.txt Pages : 15 Date : 2012-03-12 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attack. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism based on using CGAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-06.txt From bharat_joshi@infosys.com Mon Mar 12 02:03:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5CA21F8750 for ; Mon, 12 Mar 2012 02:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.304 X-Spam-Level: X-Spam-Status: No, score=-6.304 tagged_above=-999 required=5 tests=[AWL=-1.194, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kirgyJqEPDhn for ; Mon, 12 Mar 2012 02:03:34 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id D8F7B21F873D for ; Mon, 12 Mar 2012 02:03:33 -0700 (PDT) X-TM-IMSS-Message-ID: <66f1b522000d905d@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 66f1b522000d905d ; Mon, 12 Mar 2012 14:29:54 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub01.ad.infosys.com ([10.66.236.41]) with mapi; Mon, 12 Mar 2012 14:33:30 +0530 From: Bharat Joshi To: Ted Lemon Date: Mon, 12 Mar 2012 14:31:08 +0530 Thread-Topic: WGLC: draft-ietf-dhc-relay-id-suboption-09.txt Thread-Index: AQHM/w0tkeQuZjxVEUSrkbzqG08Zp5ZmXznA Message-ID: <31D55C4D55BEED48A4459EB64567589A1191364713@BLRKECMBX02.ad.infosys.com> References: <27E2BF10-7AEE-4B64-B04A-87708CB02C00@fugue.com>, <67E4F90D-7743-45A5-8595-C82DE36EC0F9@nominum.com> In-Reply-To: <67E4F90D-7743-45A5-8595-C82DE36EC0F9@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ralph Droms Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-relay-id-suboption-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 09:03:35 -0000 Ted, We had received few comments (mostly questions) but none needed a= ny changes in the text. So there is no need for a new revision of this draft at the momen= t. Regards, Bharat ________________________________________ From: Ted Lemon [Ted.Lemon@nominum.com] Sent: Sunday, March 11, 2012 3:58 AM To: Bharat Joshi Cc: Ralph Droms; dhc WG Subject: Re: WGLC: draft-ietf-dhc-relay-id-suboption-09.txt On Dec 15, 2011, at 2:17 PM, Ted Lemon wrote: > I've read the draft and it looks reasonable, but I'd like to see more = review, so I'm doing this last call in hopes that someone will take the t= ime to look at the document. Because of the Christmas and New Years' ho= lidays that some participants will be celebrating, we won't call consensu= s on this until January 5. Looks like this one fell through the cracks. I issued a last call in De= cember, scheduled to do the consensus call on January 5. As is fairly c= ommon (and perfectly fine) nobody responded until well after the deadline= , at which point we got one thorough review and a lot of support for the = document. So it passes last call, and hopefully the authors will reissue a new vers= ion that contains any changes that were suggested and that the authors th= ink make sense. Bharat Joshi, since you asked for the last call and hav= e been doing updates, can you comment on whether you have updated the doc= ument to address issues raised in last call? **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From internet-drafts@ietf.org Mon Mar 12 05:35:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A6821F8702; Mon, 12 Mar 2012 05:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsgKQmdi2HzY; Mon, 12 Mar 2012 05:35:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBB221F85E0; Mon, 12 Mar 2012 05:35:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312123513.1332.78789.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 05:35:13 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:35:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : DHCPv4 over IPv6 Transport Author(s) : Yong Cui Peng Wu Jianping Wu Ted Lemon Filename : draft-ietf-dhc-dhcpv4-over-ipv6-01.txt Pages : 10 Date : 2012-03-12 In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices using DHCPv4 with an IPv6 transport. It is done by extending DHCP client and server behavior, and by adding a new Relay Agent Information option to carry the IPv6 address of the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-ipv6-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-ipv6-01.txt From internet-drafts@ietf.org Mon Mar 12 05:46:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4AD21F873C; Mon, 12 Mar 2012 05:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtowEBleZMmH; Mon, 12 Mar 2012 05:46:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7221F873E; Mon, 12 Mar 2012 05:46:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312124610.6331.48682.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 05:46:10 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-client-id-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:46:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Client Identifier Option in DHCP Server Replies Author(s) : Narasimha Swamy Gaurav Halwasia Prashant Jhingran Filename : draft-ietf-dhc-client-id-02.txt Pages : 5 Date : 2012-03-12 This document updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' option by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. Requirements A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-client-id-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-client-id-02.txt From john_brzozowski@cable.comcast.com Mon Mar 12 11:49:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B2321F89C8 for ; Mon, 12 Mar 2012 11:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.764 X-Spam-Level: X-Spam-Status: No, score=-100.764 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH1tevsSTgGH for ; Mon, 12 Mar 2012 11:49:14 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E521E8053 for ; Mon, 12 Mar 2012 11:48:58 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.8931378; Mon, 12 Mar 2012 12:37:28 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 14:48:54 -0400 From: "Brzozowski, John" To: dhc WG Thread-Topic: IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJw== Date: Mon, 12 Mar 2012 18:48:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <0D620780F8A441429BB3BA6835B8D016@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:49:14 -0000 Folks, For those of you that have new or existing work that requires time during the IETF83 dhcwg meeting please send us mail with your request. If you have already sent us your request please confirm your request, apologies for any inconvenience. Thank you, John From internet-drafts@ietf.org Mon Mar 12 13:02:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2D21E80DB; Mon, 12 Mar 2012 13:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TomUs6yIElhB; Mon, 12 Mar 2012 13:02:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760B421E80C5; Mon, 12 Mar 2012 13:02:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312200241.15183.22101.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 13:02:41 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-bulk-leasequery-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:02:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Bulk DHCPv4 Lease Query Author(s) : Kim Kinnear Mark Stapp Bharat Joshi Neil Russell Filename : draft-ietf-dhc-dhcpv4-bulk-leasequery-06.txt Pages : 39 Date : 2012-03-12 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery extension allows a requestor to request information about DHCPv4 bindings. This mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-bulk-leasequery-0= 6.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-bulk-leasequery-06= .txt From tomasz.mrugalski@gmail.com Mon Mar 12 13:49:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED41411E80FA for ; Mon, 12 Mar 2012 13:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.17 X-Spam-Level: X-Spam-Status: No, score=-4.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0tsh8bvBAVH for ; Mon, 12 Mar 2012 13:49:08 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3114F11E80F9 for ; Mon, 12 Mar 2012 13:49:08 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1534633eaa.31 for ; Mon, 12 Mar 2012 13:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=LhoB2GYkaxR3Be62rpqwKkbw3lpNNfA4kAfi6iALDWU=; b=rJBm7jFVqI2lat1MAY3qp2KK4VSu9c09dDCFDX6C7qnE6qLIkTd6yrORxEh9tqJBiY TcGnfkPn1Ks+taeCnpWmdLkT5J4InejffQdsANMVhompSVCK3GK6j3IoZayRZRGenAzG BXwko/KW+zuGEOSm6ooGniOzLIdqu81w5AfRrVrk/O8woEgrefxAh7ZSPWd6PBIW3IG6 f5y093BW6Ks4dSFiaUm50aEyFT1cK7TGRJzD4M5y9mgkXS10SW+oOBQDpUdbYWYOLhD9 n3evYwiKH7WIxorEZ/gNRBTaxMEutWV+YnOiZWNORIxyAiaJoT0yyTKaOrTlCAbTSg7F Xzrg== Received: by 10.14.127.5 with SMTP id c5mr2105083eei.17.1331585347386; Mon, 12 Mar 2012 13:49:07 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id r44sm16451036eef.2.2012.03.12.13.49.06 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 13:49:06 -0700 (PDT) Message-ID: <4F5E613E.2050709@gmail.com> Date: Mon, 12 Mar 2012 21:49:02 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Brzozowski, John" , Ted Lemon References: In-Reply-To: X-TagToolbar-Keys: D20120312214902846 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhc WG Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:49:10 -0000 On 12.03.2012 19:48, Brzozowski, John wrote: > Folks, > > For those of you that have new or existing work that requires time during > the IETF83 dhcwg meeting please send us mail with your request. > > If you have already sent us your request please confirm your request, > apologies for any inconvenience. I would like to ask for 2 slots for the following drafts: 1. DHCPv6 failover update: 15-30 minutes, depending on time constraints this can be reasonably brief (just announcing that we have initial design, layout general ideas) or rather detailed (also present state machine with states + extra details): draft-mrugalski-dhc-dhcpv6-failover-requirements-01 draft-mrugalski-dhc-dhcpv6-failover-design-01 2. Requesting DHCPv6 Suboptions (10 minutes) draft-mrugalski-dhc-dhcpv6-suboptions-02 Other drafts that I'm involved in (and possibly could present, if needed) are listed below. I don't plan to present them unless you think that they should be presented. 3. draft-ietf-dhc-dhcpv6-redundancy-consider-02 (passed WGLC already, there is nothing to do in WG about this, authors need to update based on IESG feedback) 4. draft-mdt-softwire-map-dhcp-option-02 (I presented similar work called 4rd back then in Prague and was told to not present similar stuff before it is actually adopted by Softwires and that didn't happen yet) 5. draft-ietf-mif-dhcpv6-route-option-04 (that was presented already, there are changes since -03, but current issues are not related to DHCP-side of things, but rather related to routing aspects) Cheers, Tomek From shwethab@cisco.com Mon Mar 12 21:09:32 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2847121F87C3 for ; Mon, 12 Mar 2012 21:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.833 X-Spam-Level: X-Spam-Status: No, score=-3.833 tagged_above=-999 required=5 tests=[AWL=4.699, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5Fs3uIgf8OG for ; Mon, 12 Mar 2012 21:09:31 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4524021F87A4 for ; Mon, 12 Mar 2012 21:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=1306; q=dns/txt; s=iport; t=1331611768; x=1332821368; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ard9nruU7TH9glblMLFjA/8ZDcsHTkxCqNAeE2hx9ng=; b=aMfUrlSwAqeFFL1hmXcb2+V8kIQH/5ydX1ntWPYjmlHDcGQBDxiBCx+7 hE2nf9YLNyk8pgb6qfVvJXnCNKYo4ypY3nzpFp26kW5fTgs1Blz17fKmP /YuC3BcMoySn235Uk/0xdjFIPoozyRuB/Y1Fhld1TuncqLXH0PN2kFjh1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQIADDIXk9Io8UY/2dsb2JhbABDtV6BCYIJAQEBAwEBAQEPAScCATELBQ0BCAlkMAIEAQoDBSKHYwULnT8BnxAEijWGNASIUoUmh1SOY4FAgmuBVA X-IronPort-AV: E=Sophos;i="4.73,575,1325462400"; d="scan'208";a="7728056" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 13 Mar 2012 04:09:26 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2D49QbK030476; Tue, 13 Mar 2012 04:09:26 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 09:39:26 +0530 Received: from 173.39.64.211 ([173.39.64.211]) by XMB-BGL-417.cisco.com ([72.163.129.213]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Mar 2012 04:09:26 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 13 Mar 2012 09:43:46 +0530 From: shwethab To: "Brzozowski, John" , dhc WG Message-ID: Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Mar 2012 04:09:26.0625 (UTC) FILETIME=[14873D10:01CD00CF] Cc: Sri Gundavelli Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 04:09:32 -0000 Hi John, Request you to allocate slots for the following 3 drafts: Following 2 we would like to present and poll for wg adoption 1. draft-bhandari-dhc-class-based-prefix-01.txt - (10 mins) We had presented this in Taiwan and there was considerable interest in wg. We would like to present how this new option helps in "Prefix coloring" usecase in mobile networks 2. draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 (5 mins)- We have addressed the review comments received. There was interest expressed in wg and the mailer for this to be adopted as a wg draft. Authors of draft-ietf-dhc-client-id-02 (5 mins) have requested me to present the status of this draft and check for WG last call as there are no pending review comments. Thanks, Shwetha On 3/13/12 12:18 AM, "Brzozowski, John" wrote: > Folks, > > For those of you that have new or existing work that requires time during > the IETF83 dhcwg meeting please send us mail with your request. > > If you have already sent us your request please confirm your request, > apologies for any inconvenience. > > Thank you, > > John > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From cuiyang@huawei.com Mon Mar 12 23:39:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A9921F8805 for ; Mon, 12 Mar 2012 23:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoPzPWXgM02m for ; Mon, 12 Mar 2012 23:39:47 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C282921F87EA for ; Mon, 12 Mar 2012 23:39:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0T007JQ93O4T@szxga05-in.huawei.com> for dhcwg@ietf.org; Tue, 13 Mar 2012 14:38:12 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0T00AUI93L6Z@szxga05-in.huawei.com> for dhcwg@ietf.org; Tue, 13 Mar 2012 14:38:12 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHU38747; Tue, 13 Mar 2012 14:38:11 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 14:37:32 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.105]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 13 Mar 2012 14:38:06 +0800 Date: Tue, 13 Mar 2012 06:38:05 +0000 From: Cui Yang In-reply-to: X-Originating-IP: [10.111.49.55] To: "Brzozowski, John" , dhc WG Message-id: <8CC0CB0BCAE52F46882E17828A9AE2161A1751E5@SZXEML508-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] IETF83 dhcwg agenda items Thread-index: AQHNAIKLqqIfPWKBnE+pvzvKoI9vT5ZnxEnQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "ted.lemon@nominum.com" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 06:39:47 -0000 SGksIEpvaG4gYW5kIFRlZA0KDQpXZSBoYXZlIGp1c3QgdXBkYXRlZCBhIGRyYWZ0IG9uICJTZWN1 cml0eSBvcHRpb24gZXh0ZW5zaW9ucyBmb3IgREhDUHY0Ii4NCk1heSBJIGhhdmUgMTAgbWlucyB0 byBwcmVzZW50IHRoaXMgaW4gdGhlIGNvbWluZyBQYXJpcyBtZWV0aW5nPw0KDQpUaGUgZHJhZnQg cHJvcG9zZWQgdG8gdXNlIG5ldyBESEMgb3B0aW9ucyB0byBhc3NpZ24gY3J1Y2lhbCBzZWN1cml0 eSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMsDQp3aGljaCBoYXMgaW1wb3J0YW50IHVzZSBjYXNl cywgc3VjaCBhcywgc2VjdXJlIHNlbGYtYm9vdGluZyBpbiBuZXR3b3JrLg0KVGhhbmtzIGZvciB5 b3VyIGNvbnNpZGVyYXRpb24uDQoNCkZpbGVuYW1lOgkgZHJhZnQtYmktZGhjLXNlYy1vcHRpb24N ClJldmlzaW9uOgkgMDENClRpdGxlOgkJIFNlY3VyaXR5IG9wdGlvbiBleHRlbnNpb25zIGZvciBE SENQdjQNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTAzLTEyDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogOQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBhIG5ldyBvcHRpb24gdGhhdCBjYW4gYmUgdXNlZCBieSBESENQIHNlcnZlcnMN CiAgIHRvIGV4Y2hhbmdlIHdpdGggREhDUCBjbGllbnRzIHNwZWNpZmljIHNlY3VyaXR5IGNvbmZp Z3VyYXRpb24NCiAgIGluZm9ybWF0aW9uLiAgVGhpcyBuZXcgb3B0aW9uIGRlZmluZXMgYSBzdGFu ZGFyZCBwYXJhbWV0ZXIgZm9ybWF0IGFuZA0KICAgY29kZSBzbyB0aGF0IHRoZXJlIHdpbGwgYmUg bm8gYW1iaWd1aXR5IGluIGludGVyb3BlcmF0aW5nIHRoZQ0KICAgaW5mb3JtYXRpb24gYmVpbmcg ZXhjaGFuZ2VkIGFuZCB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gaXNzdWVzIHJlbGF0ZWQNCiAgIHRv IGludGVyb3BlcmFiaWxpdHkuICBJdCBpcyBhbiBvcHRpb24gZGVmaW5pdGlvbiBleHRlbnNpb24g Zm9yIERIQ1B2NA0KICAgd2hpY2ggc2hvdWxkIGJlIGluY2x1ZGVkIGluIFJGQyAyMTMyLg0KDQpC ZXN0IHJlZ2FyZHMsDQpZYW5nDQo9PT09PT09PT09PT09PT09PT0NCiBZYW5nIEN1aSwgIFBoLkQu DQogSHVhd2VpIFRlY2hub2xvZ2llcw0KIGN1aXlhbmdAaHVhd2VpLmNvbQ0KDQoNCj4gLS0tLS3T yrz+1K28/i0tLS0tDQo+ILeivP7IyzogQnJ6b3pvd3NraSwgSm9obiBbbWFpbHRvOkpvaG5fQnJ6 b3pvd3NraUBDYWJsZS5Db21jYXN0LmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTLE6jPUwjEzyNUgMjo0 OQ0KPiDK1bz+yMs6IGRoYyBXRw0KPiDW98ziOiBbZGhjd2ddIElFVEY4MyBkaGN3ZyBhZ2VuZGEg aXRlbXMNCj4gDQo+IEZvbGtzLA0KPiANCj4gRm9yIHRob3NlIG9mIHlvdSB0aGF0IGhhdmUgbmV3 IG9yIGV4aXN0aW5nIHdvcmsgdGhhdCByZXF1aXJlcyB0aW1lIGR1cmluZw0KPiB0aGUgSUVURjgz IGRoY3dnICBtZWV0aW5nIHBsZWFzZSBzZW5kIHVzIG1haWwgd2l0aCB5b3VyIHJlcXVlc3QuDQo+ IA0KPiBJZiB5b3UgaGF2ZSBhbHJlYWR5IHNlbnQgdXMgeW91ciByZXF1ZXN0IHBsZWFzZSBjb25m aXJtIHlvdXIgcmVxdWVzdCwNCj4gYXBvbG9naWVzIGZvciBhbnkgaW5jb252ZW5pZW5jZS4NCj4g DQo+IFRoYW5rIHlvdSwNCj4gDQo+IEpvaG4NCj4gDQoNCg== From leaf.y.yeh@huawei.com Tue Mar 13 04:09:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86E921F8749 for ; Tue, 13 Mar 2012 04:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.647 X-Spam-Level: X-Spam-Status: No, score=-6.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt+-cuI04Gep for ; Tue, 13 Mar 2012 04:09:48 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2B521F8742 for ; Tue, 13 Mar 2012 04:09:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0T000D5LMOO8@szxga04-in.huawei.com> for dhcwg@ietf.org; Tue, 13 Mar 2012 19:08:48 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0T00672LMMRY@szxga04-in.huawei.com> for dhcwg@ietf.org; Tue, 13 Mar 2012 19:08:48 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHU76990; Tue, 13 Mar 2012 19:08:41 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 19:08:36 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.217]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Tue, 13 Mar 2012 19:08:37 +0800 Date: Tue, 13 Mar 2012 11:08:36 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: "Brzozowski, John" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: IETF83 dhcwg agenda items Thread-index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5ZnzvdQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: dhc WG Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 11:09:52 -0000 Hi, Chairs I'd like to present my new draft "Authorization Option for DHCPv6 Relay Agents on Broadband Access Server" in the DHC session of IETF83 within 10 mins. Best Regards, Leaf PS. https://datatracker.ietf.org/doc/draft-yeh-dhc-dhcpv6-authorization-opt/?include_text=1 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Brzozowski, John Sent: Tuesday, March 13, 2012 2:49 AM To: dhc WG Subject: [dhcwg] IETF83 dhcwg agenda items Folks, For those of you that have new or existing work that requires time during the IETF83 dhcwg meeting please send us mail with your request. If you have already sent us your request please confirm your request, apologies for any inconvenience. Thank you, John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dankney@network1.net Tue Mar 13 06:05:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB50F21F8775 for ; Tue, 13 Mar 2012 06:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXfMAdFuBNVQ for ; Tue, 13 Mar 2012 06:05:39 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3818921F875B for ; Tue, 13 Mar 2012 06:05:38 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id E6158542773 for ; Tue, 13 Mar 2012 09:05:37 -0400 (EDT) Date: Tue, 13 Mar 2012 09:05:37 -0400 (EDT) From: perl-list To: dhc WG Message-ID: <55065be4-7d46-4ee8-9cc3-73aa9ab94483@zimbra.network1.net> In-Reply-To: Content-Type: multipart/alternative; boundary="=_435d68e9-cf83-4fde-9bd6-8c5ee5e9d6b0" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 13:05:39 -0000 --=_435d68e9-cf83-4fde-9bd6-8c5ee5e9d6b0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I am quite interested in this draft: draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 proposed by the Cisco engineers. Do you know if there will be an opportunity to view (or listen to) this meeting online somehow for those of us who cannot make it to Paris? ----- Original Message ----- > From: "John Brzozowski" > To: "dhc WG" > Sent: Monday, March 12, 2012 2:48:52 PM > Subject: [dhcwg] IETF83 dhcwg agenda items > Folks, > For those of you that have new or existing work that requires time > during > the IETF83 dhcwg meeting please send us mail with your request. > If you have already sent us your request please confirm your request, > apologies for any inconvenience. > Thank you, > John > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=_435d68e9-cf83-4fde-9bd6-8c5ee5e9d6b0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>I am quite interested in this draft: draft-hal= wasia-dhc-dhcpv6-hardware-addr-opt-01 proposed by the Cisco engineers.  Do you know if there will b= e an opportunity to view (or listen to) this meeting online somehow for tho= se of us who cannot make it to Paris?

Fro= m: "John Brzozowski" <John_Brzozowski@Cable.Comcast.com>
To= : "dhc WG" <dhcwg@ietf.org>
Sent: Monday, March 12, 201= 2 2:48:52 PM
Subject: [dhcwg] IETF83 dhcwg agenda items

Fo= lks,

For those of you that have new or existing work that requires t= ime during
the IETF83 dhcwg  meeting please send us mail with your = request.

If you have already sent us your request please confirm you= r request,
apologies for any inconvenience.

Thank you,

Joh= n

_______________________________________________
dhcwg mailing l= ist
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

--=_435d68e9-cf83-4fde-9bd6-8c5ee5e9d6b0-- From Ted.Lemon@nominum.com Tue Mar 13 06:59:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B63221F88CC for ; Tue, 13 Mar 2012 06:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeuBYXZkINBj for ; Tue, 13 Mar 2012 06:59:33 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED8521F88BB for ; Tue, 13 Mar 2012 06:59:33 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT19SxExotokFhpSGnpHBuLe+zcEGEoBZ@postini.com; Tue, 13 Mar 2012 06:59:33 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6D7AF1B82C6 for ; Tue, 13 Mar 2012 06:59:32 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DF2C019005C; Tue, 13 Mar 2012 06:59:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 13 Mar 2012 06:59:31 -0700 From: Ted Lemon To: perl-list Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5ZoqE6AgAAPDYA= Date: Tue, 13 Mar 2012 13:59:30 +0000 Message-ID: <168B1311-870B-43E2-961C-D76A099B6746@nominum.com> References: <55065be4-7d46-4ee8-9cc3-73aa9ab94483@zimbra.network1.net> In-Reply-To: <55065be4-7d46-4ee8-9cc3-73aa9ab94483@zimbra.network1.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_168B1311870B43E2961CD76A099B6746nominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 13:59:35 -0000 --_000_168B1311870B43E2961CD76A099B6746nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 13, 2012, at 9:05 AM, perl-list > wrote: I am quite interested in this draft: draft-halwasia-dhc-dhcpv6-hardware-add= r-opt-01 proposed by the Cisco engineers. Do you know if there will be an = opportunity to view (or listen to) this meeting online somehow for those of= us who cannot make it to Paris? If you go to the online agenda you will find links for the audio session, a= nd for the jabber room as well. --_000_168B1311870B43E2961CD76A099B6746nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 13, 2012, at 9:05 AM, perl-list <perl-list@network1.net> wrote:
I am quite interested in this draft: draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 proposed by the Cisco engineers.  Do you know if there will be an opportunity = to view (or listen to) this meeting online somehow for those of us who cann= ot make it to Paris?

If you go to the online agenda you will find links for the audio sessi= on, and for the jabber room as well.

--_000_168B1311870B43E2961CD76A099B6746nominumcom_-- From ichiroumakino@gmail.com Tue Mar 13 09:22:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2067A21F87ED for ; Tue, 13 Mar 2012 09:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JazTX4C-yU1x for ; Tue, 13 Mar 2012 09:22:35 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9450021F873A for ; Tue, 13 Mar 2012 09:22:34 -0700 (PDT) Received: by werb10 with SMTP id b10so879950wer.31 for ; Tue, 13 Mar 2012 09:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KqVFvqPOHSG/gAD14rtRbZltuNpR9gZmQvkSj5NnDXA=; b=dCj8ONjM21B2kPCx/0Zk5eKiilDss+Ui5uNR6fOp00lF8rlDfq4gezkjKlXB1efaSe ot6my+hlUI9Ee27WlN2iSOGROEn5gheB3an29hfEqAt9sc3mc3hs7Gj/VzdE5gVR/1hc k6B2UkItLqgCMBn7g91IOBSU2fHXqKcgLr/r/MqkJgd36UrhRJ/SPw/w0Vmzi1u8AdBJ fFAqrMiIMcz52Z2P1d7ul5zdhYXbce2f7brNzUOucXNsH0cm2p3j6tyUgsqW7KpuVRTH fsSw1lrgnI5d1cHwamJzgru1jOGjPi7QqRFuYLdx+x/4blSd/SKtXNejcieb9qNqMlVr +ebw== Received: by 10.180.102.129 with SMTP id fo1mr8919108wib.6.1331655753856; Tue, 13 Mar 2012 09:22:33 -0700 (PDT) Received: from dhcp-10-61-99-158.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm5659143wib.2.2012.03.13.09.22.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 09:22:33 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 13 Mar 2012 09:22:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1257) Cc: dhc WG Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:22:36 -0000 Chairs, > For those of you that have new or existing work that requires time = during > the IETF83 dhcwg meeting please send us mail with your request. >=20 > If you have already sent us your request please confirm your request, > apologies for any inconvenience. I'd like to ask for a slot to discuss: - the RFC3315/RFC3633 errata required by RFC6204/RFC6204bis - changes required to the DHC protocol to handle multiple stateful = options in a single session there is currently not a published draft describing all the issues, but = I've compiled a list from the mailing list discussions that will be = published ASAP. in addition I'm hoping we can get some people together = before the WG slot, so that we can report results at the Thursday = meeting. 20 minutes? cheers, Ole= From shemant@cisco.com Tue Mar 13 10:36:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FFF21E8020 for ; Tue, 13 Mar 2012 10:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.704 X-Spam-Level: X-Spam-Status: No, score=-9.704 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+aeKWufOjKT for ; Tue, 13 Mar 2012 10:36:28 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 951E821F86FC for ; Tue, 13 Mar 2012 10:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1243; q=dns/txt; s=iport; t=1331660188; x=1332869788; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=axJk2JZ/yF5H8+APcjDAejhDl2MLUwFkZTh95BHHU7g=; b=Umeco8zbA4Q0+LPvG5+o5j5Jj/Ly9tuAP+gKwt367fGj4ndH6s80dauZ ouPfT0EODgg8xmfyuJ7sQaD8HPvLf5ewEvRYbWQTlbcev5QMnel/mCF/Q ihX3XkHYi/RwRrN45KzVdUDERBT/edZAsFJomvi4HfLCFCLj32IpGb3RJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKKEX0+tJV2a/2dsb2JhbABDtWiBB4IJAQEBAwEBAQEPAR0+CwUHBAIBCBEEAQELBhcBBgEmHwkIAQEEEwgah2MFC50fAZ8QBIoxhVFjBIgiM50egwOBPg X-IronPort-AV: E=Sophos;i="4.73,578,1325462400"; d="scan'208";a="66115721" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 13 Mar 2012 17:36:28 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2DHaSPJ020684; Tue, 13 Mar 2012 17:36:28 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 12:36:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2012 12:36:27 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FE54E@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: Ac0BNYXVXRzJ+50oRb+G9PM4+D5PZwACjq4w References: From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Brzozowski, John" X-OriginalArrivalTime: 13 Mar 2012 17:36:28.0416 (UTC) FILETIME=[D22A3000:01CD013F] Cc: dhc WG Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 17:36:29 -0000 I support Ole's request. Thanks and regards, Hemant -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Tuesday, March 13, 2012 12:22 PM To: Brzozowski, John Cc: dhc WG Subject: Re: [dhcwg] IETF83 dhcwg agenda items Chairs, > For those of you that have new or existing work that requires time = during > the IETF83 dhcwg meeting please send us mail with your request. >=20 > If you have already sent us your request please confirm your request, > apologies for any inconvenience. I'd like to ask for a slot to discuss: - the RFC3315/RFC3633 errata required by RFC6204/RFC6204bis - changes required to the DHC protocol to handle multiple stateful = options in a single session there is currently not a published draft describing all the issues, but = I've compiled a list from the mailing list discussions that will be = published ASAP. in addition I'm hoping we can get some people together = before the WG slot, so that we can report results at the Thursday = meeting. 20 minutes? cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From yangtianle@hotmail.com Tue Mar 13 04:45:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A3121F87BA for ; Tue, 13 Mar 2012 04:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMGWBx2rs+jX for ; Tue, 13 Mar 2012 04:45:08 -0700 (PDT) Received: from snt0-omc1-s41.snt0.hotmail.com (snt0-omc1-s41.snt0.hotmail.com [65.54.61.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0999E21F87AF for ; Tue, 13 Mar 2012 04:45:07 -0700 (PDT) Received: from SNT120-W54 ([65.55.90.7]) by snt0-omc1-s41.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 04:45:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_724c969e-3b85-45e8-89b4-25b4f4f3d76d_" X-Originating-IP: [117.136.0.182] From: yangtianle To: Date: Tue, 13 Mar 2012 19:45:07 +0800 Importance: Normal In-Reply-To: References: <20120305083154.9797.20906.idtracker@ietfa.amsl.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 13 Mar 2012 11:45:08.0036 (UTC) FILETIME=[BD477840:01CD010E] X-Mailman-Approved-At: Tue, 13 Mar 2012 10:45:42 -0700 Subject: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 11:45:08 -0000 --_724c969e-3b85-45e8-89b4-25b4f4f3d76d_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit maybe sth wrong with my mail client, could you receive my mails now? From: yangtianle@hotmail.com To: dhcwg@ietf.org Subject: FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt Date: Mon, 5 Mar 2012 16:39:49 +0800 > From: internet-drafts@ietf.org > To: yangtianle@hotmail.com > CC: maqiongfang@chinamobile.com; yangtianle@chinamobile.com > Subject: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt > Date: Mon, 5 Mar 2012 00:31:54 -0800 > > A new version of I-D, draft-yang-dhc-ipv4-dis-00.txt has been successfully submitted by yangtianle and posted to the IETF repository. > > Filename: draft-yang-dhc-ipv4-dis > Revision: 00 > Title: Mitigating aggregated traffic of DHCP discover messages > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This document defines a new option DIS_MAX_RT which can mitigate > aggregated traffic caused by discover messages the client sends to > the server. > > > > > The IETF Secretariat --_724c969e-3b85-45e8-89b4-25b4f4f3d76d_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
maybe sth wrong with my mail client, could you receive my mails now?
 
From: yangtianle@hotmail.com
To: dhcwg@ietf.org
Subject: FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt
Date: Mon, 5 Mar 2012 16:39:49 +0800


 
> From: internet-drafts@ietf.org
> To: yangtianle@hotmail.com
> CC: maqiongfang@chinamobile.com; yangtianle@chinamobile.com
> Subject: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt
> Date: Mon, 5 Mar 2012 00:31:54 -0800
>
> A new version of I-D, draft-yang-dhc-ipv4-dis-00.txt has been successfully submitted by yangtianle and posted to the IETF repository.
>
> Filename: draft-yang-dhc-ipv4-dis
> Revision: 00
> Title: Mitigating aggregated traffic of DHCP discover messages
> Creation date: 2012-03-05
> WG ID: Individual Submission
> Number of pages: 6
>
> Abstract:
> This document defines a new option DIS_MAX_RT which can mitigate
> aggregated traffic caused by discover messages the client sends to
> the server.
>
>
>
>
> The IETF Secretariat
< /body> --_724c969e-3b85-45e8-89b4-25b4f4f3d76d_-- From yangtianle@hotmail.com Tue Mar 13 04:54:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185BC21F876F for ; Tue, 13 Mar 2012 04:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx27-ZiJvkuP for ; Tue, 13 Mar 2012 04:54:57 -0700 (PDT) Received: from snt0-omc1-s17.snt0.hotmail.com (snt0-omc1-s17.snt0.hotmail.com [65.55.90.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25321F8722 for ; Tue, 13 Mar 2012 04:54:57 -0700 (PDT) Received: from SNT120-W5 ([65.55.90.9]) by snt0-omc1-s17.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 04:54:57 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f5553c7b-6979-46b3-a4ba-dcdce4164b4a_" X-Originating-IP: [117.136.0.182] From: yangtianle To: Date: Tue, 13 Mar 2012 19:54:56 +0800 Importance: Normal In-Reply-To: References: <20120305083154.9797.20906.idtracker@ietfa.amsl.com>, , MIME-Version: 1.0 X-OriginalArrivalTime: 13 Mar 2012 11:54:57.0706 (UTC) FILETIME=[1CBFF8A0:01CD0110] X-Mailman-Approved-At: Tue, 13 Mar 2012 10:45:42 -0700 Subject: [dhcwg] New Version Notification for draft-yang-dhc-ipv4-dis-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 11:54:58 -0000 --_f5553c7b-6979-46b3-a4ba-dcdce4164b4a_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit maybe sth wrong with my mail client, could you receive my mails now? From: yangtianle@hotmail.com To: dhcwg@ietf.org Subject: FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt Date: Mon, 5 Mar 2012 16:39:49 +0800 > From: internet-drafts@ietf.org > To: yangtianle@hotmail.com > CC: maqiongfang@chinamobile.com; yangtianle@chinamobile.com > Subject: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt > Date: Mon, 5 Mar 2012 00:31:54 -0800 > > A new version of I-D, draft-yang-dhc-ipv4-dis-00.txt has been successfully submitted by yangtianle and posted to the IETF repository. > > Filename: draft-yang-dhc-ipv4-dis > Revision: 00 > Title: Mitigating aggregated traffic of DHCP discover messages > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This document defines a new option DIS_MAX_RT which can mitigate > aggregated traffic caused by discover messages the client sends to > the server. > > > > > The IETF Secretariat --_f5553c7b-6979-46b3-a4ba-dcdce4164b4a_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit



maybe sth wrong with my mail client, could you receive my mails now?
 
From: yangtianle@hotmail.com
To: dhcwg@ietf.org
Subject: FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt
Date: Mon, 5 Mar 2012 16:39:49 +0800


 
> From: internet-drafts@ietf.org
> To: yangtianle@hotmail.com
> CC: maqiongfang@chinamobile.com; yangtianle@chinamobile.com
> Subject: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt
> Date: Mon, 5 Mar 2012 00:31:54 -0800
>
> A new version of I-D, draft-yang-dhc-ipv4-dis-00.txt has been successfully submitted by yangtianle and posted to the IETF repository.
>
> Filename: draft-yang-dhc-ipv4-dis
> Revision: 00
> Title: Mitigating aggregated traffic of DHCP discover messages
> Creation date: 2012-03-05
> WG ID: Individual Submission
> Number of pages: 6
>
> Abstract:
> This document defines a new option DIS_MAX_RT which can mitigate
> aggregated traffic caused by discover messages the client sends to
> the server.
>
>
>
>
> The IETF Secretariat
--_f5553c7b-6979-46b3-a4ba-dcdce4164b4a_-- From pengwu.thu@gmail.com Tue Mar 13 19:47:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF97D21E8026 for ; Tue, 13 Mar 2012 19:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AB2MmnibAD9 for ; Tue, 13 Mar 2012 19:47:00 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id D8DFF21E800F for ; Tue, 13 Mar 2012 19:47:00 -0700 (PDT) Received: by dald2 with SMTP id d2so2679646dal.27 for ; Tue, 13 Mar 2012 19:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=x90LQab07waZQTSYfrxkvIFI1Sej9eJJv54H9hDtLZI=; b=C5PE4rA2lGNbLA1xUjpZDXW96jU3YEgI4lFRzQUP1ZveZrtFYFeNTXOzvI9G9koGJ5 Ss/Uz/ReahbWeeOXP5OSMNIjECUwGjhnY4VWp06W62dw8iwMLhRwj89yEmeB8qYVQakM 1Z1e0vQjSalncANzZKXGp4Km4YCQAvSV3PzeJ2dmnI3ujqUV+JNseeFjTDdgyI1+zTz7 OyY7boDBbRSBhtGuQYyHhAYwIU4L9xkS1KM/Q4Vq5MGXkQarRLLdJi83PjXTQGWOksAr qWnChBqsZcZfFunl/y+HbXQl67D5QSZaImuF705XdNktR48xMHiwShtCiPg3S82gIm9P LSCA== MIME-Version: 1.0 Received: by 10.68.234.1 with SMTP id ua1mr1348989pbc.69.1331693220737; Tue, 13 Mar 2012 19:47:00 -0700 (PDT) Received: by 10.68.213.2 with HTTP; Tue, 13 Mar 2012 19:47:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 10:47:00 +0800 Message-ID: From: Peng Wu To: dhc WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 02:47:01 -0000 Hi John, We'd like to request 10 min to present the update on the DHCPv4 over IPv6 Transport draft http://tools.ietf.org/id/draft-ietf-dhc-dhcpv4-over-ipv6-01.txt Thanks. 2012/3/13 Brzozowski, John : > Folks, > > For those of you that have new or existing work that requires time during > the IETF83 dhcwg =A0meeting please send us mail with your request. > > If you have already sent us your request please confirm your request, > apologies for any inconvenience. > > Thank you, > > John > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From yangtianle@hotmail.com Tue Mar 13 19:31:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF8821E8049 for ; Tue, 13 Mar 2012 19:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.697 X-Spam-Level: **** X-Spam-Status: No, score=4.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P3teaA1jWe4 for ; Tue, 13 Mar 2012 19:31:25 -0700 (PDT) Received: from snt0-omc1-s33.snt0.hotmail.com (snt0-omc1-s33.snt0.hotmail.com [65.55.90.44]) by ietfa.amsl.com (Postfix) with ESMTP id 721E921E803A for ; Tue, 13 Mar 2012 19:31:25 -0700 (PDT) Received: from SNT120-W14 ([65.55.90.9]) by snt0-omc1-s33.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 19:31:25 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_037deca2-3d96-4cb0-b53c-3f5acdc5ce24_" X-Originating-IP: [117.128.8.73] From: yangtianle To: Date: Wed, 14 Mar 2012 10:31:25 +0800 Importance: Normal In-Reply-To: <003301cd0187$e8ab5e10$ba021a30$@com> References: <20120305083154.9797.20906.idtracker@ietfa.amsl.com> <5D36713D8A4E7348A7E10DF7437A4B92191AED75@SZXEML506-MBS.china.huawei.com>, <003301cd0187$e8ab5e10$ba021a30$@com> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2012 02:31:25.0306 (UTC) FILETIME=[8D66EDA0:01CD018A] X-Mailman-Approved-At: Tue, 13 Mar 2012 20:18:49 -0700 Subject: [dhcwg] =?gb2312?b?Rlc6ILTwuLQ6ICBGVzogTmV3IFZlcnNpb24gTm90aWZp?= =?gb2312?b?Y2F0aW9uIGZvciBkcmFmdC15YW5nLWRoYy1pcHY0LWRpcy0wMC50eHQ=?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 02:31:26 -0000 --_037deca2-3d96-4cb0-b53c-3f5acdc5ce24_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Thank you for ur comments. We will share our dhcpv4 test results in Pairs meeting. ·¢¼þÈË: Sheng Jiang [mailto:jiangsheng@huawei.com] ·¢ËÍʱ¼ä: 2012Äê3ÔÂ14ÈÕ 10:03 ÊÕ¼þÈË: yangtianle; dhcwg@ietf.org ³­ËÍ: draft-yang-dhc-ipv4-dis@tools.ietf.org Ö÷Ìâ: RE: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt This document has described a valuable requirement for the current IPv4 network. It is a reasonable work that DHC WG should pick up, I think. The blow are some comments: The introduction section needs to include more motivation description. Although I believe the requirement is real and valuable, the current draft does not present it well. Some data/analysis on how high the volume of aggregated traffic at a DHCPv4 server can be would complete the motivation. ¡°keep the consistency between DHCPv4 and DHCPv6¡± is not a necessary requirement for me. DHCPv4 and DHCPv6 are independent each other and can be different of course. The summary of experiment in Section 4 is blur. The security consideration may need to be more specific. Best regards, Sheng From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of yangtianle Sent: Tuesday, March 13, 2012 7:45 PM To: dhcwg@ietf.org Subject: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt maybe sth wrong with my mail client, could you receive my mails now? From: yangtianle@hotmail.com To: dhcwg@ietf.org Subject: FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt Date: Mon, 5 Mar 2012 16:39:49 +0800 > From: internet-drafts@ietf.org > To: yangtianle@hotmail.com > CC: maqiongfang@chinamobile.com; yangtianle@chinamobile.com > Subject: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt > Date: Mon, 5 Mar 2012 00:31:54 -0800 > > A new version of I-D, draft-yang-dhc-ipv4-dis-00.txt has been successfully submitted by yangtianle and posted to the IETF repository. > > Filename: draft-yang-dhc-ipv4-dis > Revision: 00 > Title: Mitigating aggregated traffic of DHCP discover messages > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This document defines a new option DIS_MAX_RT which can mitigate > aggregated traffic caused by discover messages the client sends to > the server. > > > > > The IETF Secretariat < /body> --_037deca2-3d96-4cb0-b53c-3f5acdc5ce24_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

 

Thank you for ur comments.

We will share our dhcpv4 test results in Pairs meeting.

 

 

 

·¢¼þÈË: Sheng Jiang [mailto:jiangsheng@huawei.com]
·¢ËÍʱ¼ä: 2012Äê3ÔÂ14ÈÕ 10:03
ÊÕ¼þÈË: yangtianle; dhcwg@ietf.org
³­ËÍ: draft-yang-dhc-ipv4-dis@tools.ietf.org
Ö÷Ìâ: RE: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt

 

This document has described a valuable requirement for the current IPv4 network. It is a reasonable work that DHC WG should pick up, I think. The blow are some comments:

 

The introduction section needs to include more motivation description. Although I believe the requirement is real and valuable, the current draft does not present it well. Some data/analysis on how high the volume of aggregated traffic at a DHCPv4 server can be would complete the motivation. ¡°keep the consistency between DHCPv4 and DHCPv6¡± is not a necessary requirement for me. DHCPv4 and DHCPv6 are independent each other and can be different of course.

 

The summary of experiment in Section 4 is blur.

 

The security consideration may need to be more specific.

 

Best regards,

 

Sheng

 

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of yangtianle
Sent: Tuesday, March 13, 2012 7:45 PM
To: dhcwg@ietf.org
Subject: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt

 

maybe sth wrong with my mail client, could you receive my mails now?
 

From: yangtianle@hotmail.com
To: dhcwg@ietf.org
Subject: FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt
Date: Mon, 5 Mar 2012 16:39:49 +0800


 

> From: internet-drafts@ietf.org
> To: yangtianle@hotmail.com
> CC: maqiongfang@chinamobile.com; yangtianle@chinamobile.com
> Subject: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt
> Date: Mon, 5 Mar 2012 00:31:54 -0800
>
> A new version of I-D, draft-yang-dhc-ipv4-dis-00.txt has been successfully submitted by yangtianle and posted to the IETF repository.
>
> Filename: draft-yang-dhc-ipv4-dis
> Revision: 00
> Title: Mitigating aggregated traffic of DHCP discover messages
> Creation date: 2012-03-05
> WG ID: Individual Submission
> Number of pages: 6
>
> Abstract:
> This document defines a new option DIS_MAX_RT which can mitigate
> aggregated traffic caused by discover messages the client sends to
> the server.
>
>
>
>
&g t; The IETF Secretariat

< /body>

--_037deca2-3d96-4cb0-b53c-3f5acdc5ce24_-- From jiangsheng@huawei.com Wed Mar 14 00:39:20 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C9721F85D3 for ; Wed, 14 Mar 2012 00:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOtq1OwrSA7U for ; Wed, 14 Mar 2012 00:39:19 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DE6E521F85C3 for ; Wed, 14 Mar 2012 00:39:18 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0V00MKB6IB6L@szxga05-in.huawei.com> for dhcwg@ietf.org; Wed, 14 Mar 2012 15:37:23 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0V003K66I85S@szxga05-in.huawei.com> for dhcwg@ietf.org; Wed, 14 Mar 2012 15:37:23 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHL21903; Wed, 14 Mar 2012 15:37:23 +0800 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Mar 2012 15:36:29 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.78]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Wed, 14 Mar 2012 15:37:22 +0800 Date: Wed, 14 Mar 2012 07:37:22 +0000 From: Sheng Jiang In-reply-to: X-Originating-IP: [10.108.4.88] To: "dhcwg@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B92191AF08C@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_s0ZpBJ06sk1FW1/WPsdb/w)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt Thread-index: AQHNAUE0UXdkNeK3KE6kURtV2+Sw0pZpZ/6A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120305083154.9797.20906.idtracker@ietfa.amsl.com> Subject: Re: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 07:39:20 -0000 --Boundary_(ID_s0ZpBJ06sk1FW1/WPsdb/w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT This document has described a valuable requirement for the current IPv4 network. It is a reasonable work that DHC WG should pick up, I think. The blow are some comments: The introduction section needs to include more motivation description. Although I believe the requirement is real and valuable, the current draft does not present it well. Some data/analysis on how high the volume of aggregated traffic at a DHCPv4 server can be would complete the motivation. "keep the consistency between DHCPv4 and DHCPv6" is not a necessary requirement for me. DHCPv4 and DHCPv6 are independent each other and can be different of course. The summary of experiment in Section 4 is blur. The security consideration may need to be more specific. Best regards, Sheng From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of yangtianle Sent: Tuesday, March 13, 2012 7:45 PM To: dhcwg@ietf.org Subject: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt maybe sth wrong with my mail client, could you receive my mails now? ________________________________ From: yangtianle@hotmail.com To: dhcwg@ietf.org Subject: FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt Date: Mon, 5 Mar 2012 16:39:49 +0800 > From: internet-drafts@ietf.org > To: yangtianle@hotmail.com > CC: maqiongfang@chinamobile.com; yangtianle@chinamobile.com > Subject: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt > Date: Mon, 5 Mar 2012 00:31:54 -0800 > > A new version of I-D, draft-yang-dhc-ipv4-dis-00.txt has been successfully submitted by yangtianle and posted to the IETF repository. > > Filename: draft-yang-dhc-ipv4-dis > Revision: 00 > Title: Mitigating aggregated traffic of DHCP discover messages > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This document defines a new option DIS_MAX_RT which can mitigate > aggregated traffic caused by discover messages the client sends to > the server. > > > > > The IETF Secretariat < /body> --Boundary_(ID_s0ZpBJ06sk1FW1/WPsdb/w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

This document has describ= ed a valuable requirement for the current IPv4 network. It is a reasonable = work that DHC WG should pick up, I think. The blow are some comments:

 <= /p>

The introduction section = needs to include more motivation description. Although I believe the requir= ement is real and valuable, the current draft does not present it well. Some data/analysis on how high the volume of aggregated traffic a= t a DHCPv4 server can be would complete the motivation. “keep the con= sistency between DHCPv4 and DHCPv6” is not a necessary requirement fo= r me. DHCPv4 and DHCPv6 are independent each other and can be different of course.

 <= /p>

The summary of experiment= in Section 4 is blur.

 <= /p>

The security consideratio= n may need to be more specific.

 <= /p>

Best regards,<= /span>

 <= /p>

Sheng

 <= /p>

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of yangtianle
Sent: Tuesday, March 13, 2012 7:45 PM
To: dhcwg@ietf.org
Subject: [dhcwg] FW: New Version Notification for draft-yang-dhc-ipv= 4-dis-00.txt

 

maybe sth wron= g with my mail client, could you receive my mails now?
 

From: yangtianle@hotmail.com
To: dhcwg@ietf.org
Subject: FW: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt Date: Mon, 5 Mar 2012 16:39:49 +0800


 

> From: int= ernet-drafts@ietf.org
> To: yangtianle@hotmail.com
> CC: maqiongfang@chinamobile.com; yangtianle@chinamobile.com
> Subject: New Version Notification for draft-yang-dhc-ipv4-dis-00.txt > Date: Mon, 5 Mar 2012 00:31:54 -0800
>
> A new version of I-D, draft-yang-dhc-ipv4-dis-00.txt has been successf= ully submitted by yangtianle and posted to the IETF repository.
>
> Filename: draft-yang-dhc-ipv4-dis
> Revision: 00
> Title: Mitigating aggregated traffic of DHCP discover messages
> Creation date: 2012-03-05
> WG ID: Individual Submission
> Number of pages: 6
>
> Abstract:
> This document defines a new option DIS_MAX_RT which can mitigate
> aggregated traffic caused by discover messages the client sends to
> the server.
>
>
>
>
> The IETF Secretariat

< /body>

--Boundary_(ID_s0ZpBJ06sk1FW1/WPsdb/w)-- From shemant@cisco.com Thu Mar 15 07:09:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F05421F8602 for ; Thu, 15 Mar 2012 07:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.939 X-Spam-Level: X-Spam-Status: No, score=-9.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9m7cDCdNiwb for ; Thu, 15 Mar 2012 07:09:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CA61A21F85D8 for ; Thu, 15 Mar 2012 07:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2662; q=dns/txt; s=iport; t=1331820595; x=1333030195; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QVsJG7iVLeH/kCwc0G7JiCZP/gk37cALsyNOpHK70kQ=; b=iJLw7ymZvGzeWuwOGy2hI7EHWUFwluPeY1WbjUYBdaYJ7RwwhG+va5md iJtOySeyZQp975LU5oBKyJW+uYySt2Hqm5CF+ZIr4kp7qcXQVBWPx0HzE bLcH3QtXgYNc16Ep4ootgoeMQV0KlktiXCuzZIXz5i5822kbQCtORP1Zc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN72YU+tJV2c/2dsb2JhbABDti6BB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBCwYXAQYBJh8JCAIEARIIGodjBQudGpc5BIpBhWNjBIhXm0mBaIMEgT4 X-IronPort-AV: E=Sophos;i="4.73,591,1325462400"; d="scan'208";a="66731778" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 15 Mar 2012 14:09:55 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2FE9tRo022411; Thu, 15 Mar 2012 14:09:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 09:09:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Mar 2012 09:09:54 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C57@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7A= References: From: "Hemant Singh (shemant)" To: "Shwetha Bhandari (shwethab)" , "Brzozowski, John" , "dhc WG" X-OriginalArrivalTime: 15 Mar 2012 14:09:55.0587 (UTC) FILETIME=[4C4A0D30:01CD02B5] Cc: "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:09:57 -0000 Woj, It would be good to provide context and more descriptive use cases for the draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01. Specifically which set of SP's or any other standards body outside of the IETF have asked for such work? With additional data, we all can see what else can be done. At the last IETF, JohnB (co-Chair) suggested to use a vendor-specific option and I agree with him. IPv6 is already deployed in cable broadband for dual-stack IP services just fine with the Cisco CNR (DHCPv6 server) and backend provisioning systems in the BACC. Such a deployment already knows how to associate a dual-stack client. =20 A few others who have responded to move the draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 forward in the DHC WG should also articulate what their use case is and what is the showstopper problem they have that the IETF should look into this work. Thanks, Hemant -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Shwetha Bhandari (shwethab) Sent: Tuesday, March 13, 2012 12:14 AM To: Brzozowski, John; dhc WG Cc: Sri Gundavelli (sgundave) Subject: Re: [dhcwg] IETF83 dhcwg agenda items Hi John, Request you to allocate slots for the following 3 drafts: Following 2 we would like to present and poll for wg adoption 1. draft-bhandari-dhc-class-based-prefix-01.txt - (10 mins) We had presented this in Taiwan and there was considerable interest in wg. We would like to present how this new option helps in "Prefix coloring" usecase in mobile networks =20 2. draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 (5 mins)- We have addressed the review comments received. There was interest expressed in wg and the mailer for this to be adopted as a wg draft. Authors of draft-ietf-dhc-client-id-02 (5 mins) have requested me to present the status of this draft and check for WG last call as there are no pending review comments. Thanks, Shwetha On 3/13/12 12:18 AM, "Brzozowski, John" wrote: > Folks, >=20 > For those of you that have new or existing work that requires time during > the IETF83 dhcwg meeting please send us mail with your request. >=20 > If you have already sent us your request please confirm your request, > apologies for any inconvenience. >=20 > Thank you, >=20 > John >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dankney@network1.net Thu Mar 15 09:11:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB5D21F86C8 for ; Thu, 15 Mar 2012 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gitJ7LkMthB1 for ; Thu, 15 Mar 2012 09:11:06 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2B24121F86E4 for ; Thu, 15 Mar 2012 09:11:06 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 2E17F542934; Thu, 15 Mar 2012 12:11:04 -0400 (EDT) Date: Thu, 15 Mar 2012 12:11:04 -0400 (EDT) From: perl-list To: "Hemant Singh (shemant)" Message-ID: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C57@XMB-RCD-109.cisco.com> Content-Type: multipart/alternative; boundary="=_5108158a-2ea8-4cf4-835a-d9e98a3e2bc6" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:11:11 -0000 --=_5108158a-2ea8-4cf4-835a-d9e98a3e2bc6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hemant, This summary, after a 160+ post thread from the isc mail group dhcp-users, should sum up the need for a hardware option quite nicely: DHCPv6 host-identifier, the Never Ending Thread: A Summary https://lists.isc.org/pipermail/dhcp-users/2009-March/008678.html ----- Original Message ----- > From: "Hemant Singh (shemant)" > To: "Shwetha Bhandari (shwethab)" , "John > Brzozowski" , "dhc WG" > > Cc: "Wojciech Dec (wdec)" > Sent: Thursday, March 15, 2012 10:09:54 AM > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > Woj, > It would be good to provide context and more descriptive use cases > for > the draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01. Specifically > which > set of SP's or any other standards body outside of the IETF have > asked > for such work? With additional data, we all can see what else can be > done. At the last IETF, JohnB (co-Chair) suggested to use a > vendor-specific option and I agree with him. IPv6 is already deployed > in cable broadband for dual-stack IP services just fine with the > Cisco > CNR (DHCPv6 server) and backend provisioning systems in the BACC. > Such a > deployment already knows how to associate a dual-stack client. > A few others who have responded to move the > draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 forward in the DHC WG > should also articulate what their use case is and what is the > showstopper problem they have that the IETF should look into this > work. > Thanks, > Hemant > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > Behalf > Of Shwetha Bhandari (shwethab) > Sent: Tuesday, March 13, 2012 12:14 AM > To: Brzozowski, John; dhc WG > Cc: Sri Gundavelli (sgundave) > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > Hi John, > Request you to allocate slots for the following 3 drafts: > Following 2 we would like to present and poll for wg adoption > 1. draft-bhandari-dhc-class-based-prefix-01.txt - (10 mins) We had > presented > this in Taiwan and there was considerable interest in wg. We would > like > to > present how this new option helps in "Prefix coloring" usecase in > mobile > networks > 2. draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 (5 mins)- We have > addressed the review comments received. There was interest expressed > in > wg > and the mailer for this to be adopted as a wg draft. > Authors of draft-ietf-dhc-client-id-02 (5 mins) have requested me to > present > the status of this draft and check for WG last call as there are no > pending > review comments. > Thanks, > Shwetha > On 3/13/12 12:18 AM, "Brzozowski, John" > > wrote: > > Folks, > > > > For those of you that have new or existing work that requires time > during > > the IETF83 dhcwg meeting please send us mail with your request. > > > > If you have already sent us your request please confirm your > > request, > > apologies for any inconvenience. > > > > Thank you, > > > > John > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=_5108158a-2ea8-4cf4-835a-d9e98a3e2bc6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>Hemant,

= This summary, after a 160+ post thread from the isc mail group dhcp-users, = should sum up the need for a hardware option quite nicely:
DHCPv6 host-ident= ifier, the Never Ending Thread: A Summary
https://lists.isc.org/pipermail/dhcp-users/= 2009-March/008678.html


From: <= /b>"Hemant Singh (shemant)" <shemant@cisco.com>
To: "Shweth= a Bhandari (shwethab)" <shwethab@cisco.com>, "John Brzozowski" <Jo= hn_Brzozowski@Cable.Comcast.com>, "dhc WG" <dhcwg@ietf.org>
= Cc: "Wojciech Dec (wdec)" <wdec@cisco.com>
Sent: Thursd= ay, March 15, 2012 10:09:54 AM
Subject: Re: [dhcwg] IETF83 dhcwg = agenda items

Woj,

It would be good to provide context and mor= e descriptive use cases for
the draft-halwasia-dhc-dhcpv6-hardware-addr-= opt-01.  Specifically which
set of SP's or any other standards body= outside of the IETF have asked
for such work?  With additional dat= a, we all can see what else can be
done.  At the last IETF, JohnB (= co-Chair) suggested to use a
vendor-specific option and I agree with him= .  IPv6 is already deployed
in cable broadband for dual-stack IP se= rvices just fine with the Cisco
CNR (DHCPv6 server) and backend provisio= ning systems in the BACC. Such a
deployment already knows how to associa= te a dual-stack client.  

A few others who have responded to mo= ve the
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 forward in the DHC= WG
should also articulate what their use case is and what is the
sho= wstopper problem they have that the IETF should look into this work.

Thanks,

Hemant

-----Original Message-----
From: dhcwg= -bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
Of Shwetha B= handari (shwethab)
Sent: Tuesday, March 13, 2012 12:14 AM
To: Brzozow= ski, John; dhc WG
Cc: Sri Gundavelli (sgundave)
Subject: Re: [dhcwg] = IETF83 dhcwg agenda items

Hi John,

Request you to allocate sl= ots for the following 3 drafts:

Following 2 we would like to present= and poll for wg adoption
1. draft-bhandari-dhc-class-based-prefix-01.tx= t - (10 mins) We had
presented
this in Taiwan and there was considera= ble interest in wg. We would like
to
present how this new option help= s in "Prefix coloring" usecase in mobile
networks  
2. draft-ha= lwasia-dhc-dhcpv6-hardware-addr-opt-01 (5 mins)- We have
addressed the r= eview comments received. There was interest expressed in
wg
and the m= ailer for this to be adopted as a wg draft.

Authors of draft-ietf-dh= c-client-id-02 (5 mins) have requested me to
present
the status of th= is draft and check for WG last call as there are no
pending
review co= mments.

Thanks,
Shwetha


On 3/13/12 12:18 AM, "Brzozows= ki, John"
<John_Brzozowski@Cable.Comcast.com>
wrote:

>= ; Folks,
>
> For those of you that have new or existing work t= hat requires time
during
> the IETF83 dhcwg  meeting please s= end us mail with your request.
>
> If you have already sent us= your request please confirm your request,
> apologies for any inconv= enience.
>
> Thank you,
>
> John
>
>= _______________________________________________
> dhcwg mailing list=
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg=

_______________________________________________
dhcwg mailing li= st
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
____= ___________________________________________
dhcwg mailing list
dhcwg@= ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


--=_5108158a-2ea8-4cf4-835a-d9e98a3e2bc6-- From dankney@network1.net Thu Mar 15 09:19:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD8F21F8773 for ; Thu, 15 Mar 2012 09:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mMMDdNc5DZo for ; Thu, 15 Mar 2012 09:19:45 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0814321F8669 for ; Thu, 15 Mar 2012 09:19:45 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id A6D48542934; Thu, 15 Mar 2012 12:19:44 -0400 (EDT) Date: Thu, 15 Mar 2012 12:19:44 -0400 (EDT) From: perl-list To: "Hemant Singh (shemant)" Message-ID: <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> In-Reply-To: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> Content-Type: multipart/alternative; boundary="=_388de378-1c3d-4d97-9560-de3a17363585" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:19:46 -0000 --=_388de378-1c3d-4d97-9560-de3a17363585 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit In case you are curious about the original 160+ message thread, here is a link to it: host-identifier with IPv6 https://lists.isc.org/pipermail/dhcp-users/2009-March/008489.html ----- Original Message ----- > From: "perl-list" > To: "Hemant Singh (shemant)" > Cc: "dhc WG" , "Wojciech Dec (wdec)" > Sent: Thursday, March 15, 2012 12:11:04 PM > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > Hemant, > This summary, after a 160+ post thread from the isc mail group > dhcp-users, should sum up the need for a hardware option quite > nicely: > DHCPv6 host-identifier, the Never Ending Thread: A Summary > https://lists.isc.org/pipermail/dhcp-users/2009-March/008678.html > ----- Original Message ----- > > From: "Hemant Singh (shemant)" > > > To: "Shwetha Bhandari (shwethab)" , "John > > Brzozowski" , "dhc WG" > > > > > Cc: "Wojciech Dec (wdec)" > > > Sent: Thursday, March 15, 2012 10:09:54 AM > > > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > > > Woj, > > > It would be good to provide context and more descriptive use cases > > for > > > the draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01. Specifically > > which > > > set of SP's or any other standards body outside of the IETF have > > asked > > > for such work? With additional data, we all can see what else can > > be > > > done. At the last IETF, JohnB (co-Chair) suggested to use a > > > vendor-specific option and I agree with him. IPv6 is already > > deployed > > > in cable broadband for dual-stack IP services just fine with the > > Cisco > > > CNR (DHCPv6 server) and backend provisioning systems in the BACC. > > Such a > > > deployment already knows how to associate a dual-stack client. > > > A few others who have responded to move the > > > draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 forward in the DHC > > WG > > > should also articulate what their use case is and what is the > > > showstopper problem they have that the IETF should look into this > > work. > > > Thanks, > > > Hemant > > > -----Original Message----- > > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > > Behalf > > > Of Shwetha Bhandari (shwethab) > > > Sent: Tuesday, March 13, 2012 12:14 AM > > > To: Brzozowski, John; dhc WG > > > Cc: Sri Gundavelli (sgundave) > > > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > > > Hi John, > > > Request you to allocate slots for the following 3 drafts: > > > Following 2 we would like to present and poll for wg adoption > > > 1. draft-bhandari-dhc-class-based-prefix-01.txt - (10 mins) We had > > > presented > > > this in Taiwan and there was considerable interest in wg. We would > > like > > > to > > > present how this new option helps in "Prefix coloring" usecase in > > mobile > > > networks > > > 2. draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 (5 mins)- We have > > > addressed the review comments received. There was interest > > expressed > > in > > > wg > > > and the mailer for this to be adopted as a wg draft. > > > Authors of draft-ietf-dhc-client-id-02 (5 mins) have requested me > > to > > > present > > > the status of this draft and check for WG last call as there are no > > > pending > > > review comments. > > > Thanks, > > > Shwetha > > > On 3/13/12 12:18 AM, "Brzozowski, John" > > > > > > wrote: > > > > Folks, > > > > > > > > For those of you that have new or existing work that requires > > > time > > > during > > > > the IETF83 dhcwg meeting please send us mail with your request. > > > > > > > > If you have already sent us your request please confirm your > > > request, > > > > apologies for any inconvenience. > > > > > > > > Thank you, > > > > > > > > John > > > > > > > > _______________________________________________ > > > > dhcwg mailing list > > > > dhcwg@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=_388de378-1c3d-4d97-9560-de3a17363585 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>In case you are curious about the orig= inal 160+ message thread, here is a link to it:

host-identifier with IPv6
https://list= s.isc.org/pipermail/dhcp-users/2009-March/008489.html

=
From: "perl-list" <perl-list@network1.net>= ;
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Cc= : "dhc WG" <dhcwg@ietf.org>, "Wojciech Dec (wdec)" <wdec@cisco= .com>
Sent: Thursday, March 15, 2012 12:11:04 PM
Subject= : Re: [dhcwg] IETF83 dhcwg agenda items

<= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>I f= ully support adding the hardware address to the DHCP messages however that = happens.  If it means replacing the DUID that is very much fine with m= e.  In whatever shape or form the hardware address makes it in the pac= ket, I would be very happy to see it there as it would make implementation = of parity between DHCPv4 and DHCPv6 clients MUCH simpler as we move into th= e dual-stack period of the Internet.  Currently it is very nearly impo= ssible to have parity without some special vendor equipment of some kind, a= s far as I can tell (ISC DHCP 4.2.3) on a consistent basis. Not all clients= use the hardware address to generate the DUID per RFC. Without the hardwar= e address there, telling which DHCPv4 client matches which DHCPv6 client is= not possible.


From: "Hemant Singh (= shemant)" <shemant@cisco.com>
To: "perl-list" <perl-list= @network1.net>
Cc: "dhc WG" <dhcwg@ietf.org>, "Wojciech = Dec (wdec)" <wdec@cisco.com>
Sent: Thursday, March 15, 2012= 1:22:39 PM
Subject: RE: [dhcwg] IETF83 dhcwg agenda items

Thanks much for the URL to the details= .   Woj=E2=80=99s documents mentions a slightly different problem= which is how does an SP find dual-stack DHCPv4 and DHCPv6 clients. &n= bsp; To that problem, I already pointed to products and cable deployment th= at already knows how to ID clients that are dual-stack in the SP network.&n= bsp;   The new links sent to me are more of a Enterprise deployme= nt.  

I pref= er cleaner solutions but my thought will not be liked by DHCPv6 server vend= ors nor relay vendors.   Forget adding a new hardware option to D= HCPv6.  DHCPv6 made a fundamental mistake excluding the hardware addre= ss from the protocol.   So ack that mistake, remove the DUID from= the protocol, and replace the DUID with the chaddr of DHCPv4.   = Most hosts implemented a changing DUID (DUID-LLT) on each client reset and = the server allocated a new PD to each client!  Not to mention how does= an admin of the DHCPv6 server identify DHCPv6 clients if the DUID changed = on each client reset?    For the IPv6 CE router RFC 6204, be= cause the document limits itself to one device in the IPv6 CE router, we co= uld  tighten the language to force the device to keep the DUID persist= ent.   See bullet W-6 in http://tools.ietf.org/html/rfc6204

<= p class=3D"MsoNormal"> 

Regards,

 

Hemant

 

<= b>From: perl-list [mailto:perl-list@netw= ork1.net]
Sent: Thursday, March 15, 2012 12:20 PM
To: = Hemant Singh (shemant)
Cc: dhc WG; Wojciech Dec (wdec)
Subj= ect: Re: [dhcwg] IETF83 dhcwg agenda items

 

In case you are curious about the original = 160+ message thread, here is a link to it:

 <= /p>

host-identifier with IPv6

https://lists= .isc.org/pipermail/dhcp-users/2009-March/008489.html

&nbs= p;

From: "= perl-list" <perl-list@network1.net>
To: "Hemant Singh (shem= ant)" <shemant@cisco.com>
Cc: "dhc WG" <dhcwg@ietf.org&g= t;, "Wojciech Dec (wdec)" <wdec@cisco.com>
Sent: Thursday, = March 15, 2012 12:11:04 PM
Subject: Re: [dhcwg] IETF83 dhcwg agen= da items

Hemant,

 

This summary, after a 160= + post thread from the isc mail group dhcp-users, should sum up the need fo= r a hardware option quite nicely:

 

DHCPv6 host-id= entifier, the Never Ending Thread: A Summary

https://lists.= isc.org/pipermail/dhcp-users/2009-March/008678.html

 = ;

From: "= Hemant Singh (shemant)" <shemant@cisco.com>
To: "Shwetha Bh= andari (shwethab)" <shwethab@cisco.com>, "John Brzozowski" <John_B= rzozowski@Cable.Comcast.com>, "dhc WG" <dhcwg@ietf.org>
Cc: = "Wojciech Dec (wdec)" <wdec@cisco.com>
Sent: Thursday, = March 15, 2012 10:09:54 AM
Subject: Re: [dhcwg] IETF83 dhcwg agen= da items

Woj,

It would be good to provide context and more de= scriptive use cases for
the draft-halwasia-dhc-dhcpv6-hardware-addr-opt-= 01.  Specifically which
set of SP's or any other standards body out= side of the IETF have asked
for such work?  With additional data, w= e all can see what else can be
done.  At the last IETF, JohnB (co-C= hair) suggested to use a
vendor-specific option and I agree with him. &n= bsp;IPv6 is already deployed
in cable broadband for dual-stack IP servic= es just fine with the Cisco
CNR (DHCPv6 server) and backend provisioning= systems in the BACC. Such a
deployment already knows how to associate a= dual-stack client.  

A few others who have responded to move t= he
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 forward in the DHC WG<= br>should also articulate what their use case is and what is the
showsto= pper problem they have that the IETF should look into this work.

Thanks,

Hemant

-----Original Message-----
From: dhcwg-bou= nces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
Of Shwetha Bhand= ari (shwethab)
Sent: Tuesday, March 13, 2012 12:14 AM
To: Brzozowski,= John; dhc WG
Cc: Sri Gundavelli (sgundave)
Subject: Re: [dhcwg] IETF= 83 dhcwg agenda items

Hi John,

Request you to allocate slots = for the following 3 drafts:

Following 2 we would like to present and= poll for wg adoption
1. draft-bhandari-dhc-class-based-prefix-01.txt - = (10 mins) We had
presented
this in Taiwan and there was considerable = interest in wg. We would like
to
present how this new option helps in= "Prefix coloring" usecase in mobile
networks  
2. draft-halwas= ia-dhc-dhcpv6-hardware-addr-opt-01 (5 mins)- We have
addressed the revie= w comments received. There was interest expressed in
wg
and the maile= r for this to be adopted as a wg draft.

Authors of draft-ietf-dhc-cl= ient-id-02 (5 mins) have requested me to
present
the status of this d= raft and check for WG last call as there are no
pending
review commen= ts.

Thanks,
Shwetha


On 3/13/12 12:18 AM, "Brzozowski, = John"
<John_Brzozowski@Cable.Comcast.com>
wrote:

> Fo= lks,
>
> For those of you that have new or existing work that = requires time
during
> the IETF83 dhcwg  meeting please send = us mail with your request.
>
> If you have already sent us you= r request please confirm your request,
> apologies for any inconvenie= nce.
>
> Thank you,
>
> John
>
> ___= ____________________________________________
> dhcwg mailing list
= > dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
=
_______________________________________________
dhcwg mailing listdhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
________= _______________________________________
dhcwg mailing list
dhcwg@ietf= .org
https://www.ietf.org/mailman/listinfo/dhcwg

=

 


_____________________________________= __________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/= mailman/listinfo/dhcwg

 


--=_7e50f414-2d6d-4fb7-b6e1-61fec231d258-- From shemant@cisco.com Thu Mar 15 12:01:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9262321F8711 for ; Thu, 15 Mar 2012 12:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6keVWvyWMez for ; Thu, 15 Mar 2012 12:00:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4247721E802D for ; Thu, 15 Mar 2012 12:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=35006; q=dns/txt; s=iport; t=1331838041; x=1333047641; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=LvbnALTL9ttfNlzVssYNs2GBWgDHXPRWqsGDAEVS1mI=; b=Z7O+1FNTCCkrj3wHIMqWQsJsTcHUIIz5de7brpH266QUDb81Uf4wDfLc bNbuM4wJ/30pm54zVQTqNaWbc5DpqEfvF/aelMZ52buXH65MTH6FUeAq2 8OA05vNo7rnsRXOPC3iOojP2D0KF6Qd9Qo6CRnlnmgyEFl/D8sUiMNIWG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABE8Yk+tJXHA/2dsb2JhbAA5CoJFgnevb36BB4IJAQEBAwEBAQEPAQkHCgM+CwUHBAIBCBEEAQELBhAHAQICAgEBJQEeCQgBAQQTCBMHh2MFC5psjQSSB4o4CYUwM2MEiFeKX5BqgWiDBIE+ X-IronPort-AV: E=Sophos;i="4.73,592,1325462400"; d="scan'208,217";a="66827270" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 15 Mar 2012 19:00:30 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2FJ0U5l009107; Thu, 15 Mar 2012 19:00:30 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 14:00:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD02DD.E0E018B8" Date: Thu, 15 Mar 2012 14:00:23 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1E17@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: Ac0C2MVxYd+fbdTgQ2Kv1KmDihJapQAAw90w References: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "perl-list" X-OriginalArrivalTime: 15 Mar 2012 19:00:26.0385 (UTC) FILETIME=[E1DAC010:01CD02DD] Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:01:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD02DD.E0E018B8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIG5vdGUgdGhhdCBvbmUgcmVhc29uIEkgaGF2ZSBoZWFyZCB3aHkgdGhlIERVSUQgd2Fz IGludHJvZHVjZWQgaW4gREhDUHY2IGlzIGFsc28gaW5jbHVkZWQgaW4gdGhlIGZvbGxvd2luZyB0 ZXh0IGZvciBSRkMgMzMxNS4NCg0KIA0KDQpbYSBkZXZpY2UncyBEVUlEIHNob3VsZCBub3QgY2hh bmdlIGFzIGEgcmVzdWx0IG9mIGEgY2hhbmdlIGluDQoNCnRoZSBkZXZpY2UncyBuZXR3b3JrIGhh cmR3YXJlLl0NCg0KIA0KDQpIb3cgbXVjaCB0byBhZG1pbnMgb2YgbmV0d29ya3MgYW5kIERIQ1B2 NiBzZXJ2ZXIgY2FyZSBhYm91dCBjaGFuZ2VkIE5JQyBjYXJkIGluIGEgUEMgdGhhdCBpcyBhbHNv IGEgREhDUHY2IGNsaWVudD8gIFdoeSBub3QganVzdCBjYWxsIG9uZSdzIGFkbWluIHRvIHJlcG9y dCBhIGNoYW5nZWQgTklDIGNhcmQuICBMYXB0b3BzIG5vdyBoYXZlIGJ1aWx0LWluIHdpcmVsZXNz IGFuZCB0aGVyZSBpcyBubyBFdGhlcm5ldCBoYXJkd2FyZSBjaGFuZ2luZyBvbiBzdWNoIG1hY2hp bmVzLiAgSWYgZm9sa3MgYXJlIHdpbGxpbmcgdG8gZ2l2ZSB1cCB0aGUg4oCcY2hhbmdlZCBOSUMg Y2FyZOKAnSByZXF1aXJlbWVudCwgb25lIGNvdWxkIGRpc3BlbnNlIHdpdGggdGhlIERVSUQuICAg SSBwcmVmZXIgb25lIGlkZW50aWZpZXIgdG8gaWRlbnRpZnkgYSBjbGllbnQgaW4gZWl0aGVyIG9m IGhhcmR3YXJlIGFkZHJlc3Mgb3IgRFVJRCBidXQgbm90IGJvdGguICBUaHVzIGlmIGZvbGtzIHdh bnQgYSBoYXJkd2FyZSBhZGRyZXNzLCB0aGVuIG9uZSBjb3VsZCBjb25zaWRlciBkZXByZWNhdGlu ZyB0aGUgRFVJRC4NCg0KIA0KDQpNeSBpbnRlbnQgaXMgdG8gbm90IHJvY2sgdGhlIGJvYXQgYmVj YXVzZSBTUHMgYXJlIHBsYW5uaW5nIG9uIERIQ1B2NiBkZXBsb3ltZW50cyBhcyB3ZSBzcGVhay4g IEhvd2V2ZXIsIGlmIHRoZSBwcm90b2NvbCBpcyBjaGFuZ2luZyBmb3IgaGFyZHdhcmUgYWRkcmVz cyBpbmNsdXNpb24gd2h5IG5vdCBtYWtlIGEgY2xlYW4gY2hhbmdlIHJhdGhlciB0aGFuIGEgYmFu ZC1haWQgdGhhdCBoYXMgYSBESENQdjYgcHJvdG9jb2wgdGhhdCBzdXBwb3J0cyBib3RoIERVSUQg YW5kIGhhcmR3YXJlIGFkZHJlc3MuDQoNCiANCg0KSGVtYW50IA0KDQogDQoNCkZyb206IHBlcmwt bGlzdCBbbWFpbHRvOnBlcmwtbGlzdEBuZXR3b3JrMS5uZXRdIA0KDQpTZW50OiBUaHVyc2RheSwg TWFyY2ggMTUsIDIwMTIgMjoyNCBQTQ0KDQpUbzogSGVtYW50IFNpbmdoIChzaGVtYW50KQ0KDQpD YzogZGhjIFdHOyBXb2pjaWVjaCBEZWMgKHdkZWMpDQoNClN1YmplY3Q6IFJlOiBbZGhjd2ddIElF VEY4MyBkaGN3ZyBhZ2VuZGEgaXRlbXMNCg0KIA0KDQpJIGZ1bGx5IHN1cHBvcnQgYWRkaW5nIHRo ZSBoYXJkd2FyZSBhZGRyZXNzIHRvIHRoZSBESENQIG1lc3NhZ2VzIGhvd2V2ZXIgdGhhdCBoYXBw ZW5zLiAgSWYgaXQgbWVhbnMgcmVwbGFjaW5nIHRoZSBEVUlEIHRoYXQgaXMgdmVyeSBtdWNoIGZp bmUgd2l0aCBtZS4gIEluIHdoYXRldmVyIHNoYXBlIG9yIGZvcm0gdGhlIGhhcmR3YXJlIGFkZHJl c3MgbWFrZXMgaXQgaW4gdGhlIHBhY2tldCwgSSB3b3VsZCBiZSB2ZXJ5IGhhcHB5IHRvIHNlZSBp dCB0aGVyZSBhcyBpdCB3b3VsZCBtYWtlIGltcGxlbWVudGF0aW9uIG9mIHBhcml0eSBiZXR3ZWVu IERIQ1B2NCBhbmQgREhDUHY2IGNsaWVudHMgTVVDSCBzaW1wbGVyIGFzIHdlIG1vdmUgaW50byB0 aGUgZHVhbC1zdGFjayBwZXJpb2Qgb2YgdGhlIEludGVybmV0LiAgQ3VycmVudGx5IGl0IGlzIHZl cnkgbmVhcmx5IGltcG9zc2libGUgdG8gaGF2ZSBwYXJpdHkgd2l0aG91dCBzb21lIHNwZWNpYWwg dmVuZG9yIGVxdWlwbWVudCBvZiBzb21lIGtpbmQsIGFzIGZhciBhcyBJIGNhbiB0ZWxsIChJU0Mg REhDUCA0LjIuMykgb24gYSBjb25zaXN0ZW50IGJhc2lzLiBOb3QgYWxsIGNsaWVudHMgdXNlIHRo ZSBoYXJkd2FyZSBhZGRyZXNzIHRvIGdlbmVyYXRlIHRoZSBEVUlEIHBlciBSRkMuIFdpdGhvdXQg dGhlIGhhcmR3YXJlIGFkZHJlc3MgdGhlcmUsIHRlbGxpbmcgd2hpY2ggREhDUHY0IGNsaWVudCBt YXRjaGVzIHdoaWNoIERIQ1B2NiBjbGllbnQgaXMgbm90IHBvc3NpYmxlLg0KDQogDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogIkhlbWFudCBTaW5n aCAoc2hlbWFudCkiIDxzaGVtYW50QGNpc2NvLmNvbT4NCg0KVG86ICJwZXJsLWxpc3QiIDxwZXJs LWxpc3RAbmV0d29yazEubmV0Pg0KDQpDYzogImRoYyBXRyIgPGRoY3dnQGlldGYub3JnPiwgIldv amNpZWNoIERlYyAod2RlYykiIDx3ZGVjQGNpc2NvLmNvbT4NCg0KU2VudDogVGh1cnNkYXksIE1h cmNoIDE1LCAyMDEyIDE6MjI6MzkgUE0NCg0KU3ViamVjdDogUkU6IFtkaGN3Z10gSUVURjgzIGRo Y3dnIGFnZW5kYSBpdGVtcw0KDQogDQoNCiANCg0KVGhhbmtzIG11Y2ggZm9yIHRoZSBVUkwgdG8g dGhlIGRldGFpbHMuICAgV29q4oCZcyBkb2N1bWVudHMgbWVudGlvbnMgYSBzbGlnaHRseSBkaWZm ZXJlbnQgcHJvYmxlbSB3aGljaCBpcyBob3cgZG9lcyBhbiBTUCBmaW5kIGR1YWwtc3RhY2sgREhD UHY0IGFuZCBESENQdjYgY2xpZW50cy4gICBUbyB0aGF0IHByb2JsZW0sIEkgYWxyZWFkeSBwb2lu dGVkIHRvIHByb2R1Y3RzIGFuZCBjYWJsZSBkZXBsb3ltZW50IHRoYXQgYWxyZWFkeSBrbm93cyBo b3cgdG8gSUQgY2xpZW50cyB0aGF0IGFyZSBkdWFsLXN0YWNrIGluIHRoZSBTUCBuZXR3b3JrLiAg ICBUaGUgbmV3IGxpbmtzIHNlbnQgdG8gbWUgYXJlIG1vcmUgb2YgYSBFbnRlcnByaXNlIGRlcGxv eW1lbnQuICAgDQoNCiANCg0KSSBwcmVmZXIgY2xlYW5lciBzb2x1dGlvbnMgYnV0IG15IHRob3Vn aHQgd2lsbCBub3QgYmUgbGlrZWQgYnkgREhDUHY2IHNlcnZlciB2ZW5kb3JzIG5vciByZWxheSB2 ZW5kb3JzLiAgIEZvcmdldCBhZGRpbmcgYSBuZXcgaGFyZHdhcmUgb3B0aW9uIHRvIERIQ1B2Ni4g IERIQ1B2NiBtYWRlIGEgZnVuZGFtZW50YWwgbWlzdGFrZSBleGNsdWRpbmcgdGhlIGhhcmR3YXJl IGFkZHJlc3MgZnJvbSB0aGUgcHJvdG9jb2wuICAgU28gYWNrIHRoYXQgbWlzdGFrZSwgcmVtb3Zl IHRoZSBEVUlEIGZyb20gdGhlIHByb3RvY29sLCBhbmQgcmVwbGFjZSB0aGUgRFVJRCB3aXRoIHRo ZSBjaGFkZHIgb2YgREhDUHY0LiAgIE1vc3QgaG9zdHMgaW1wbGVtZW50ZWQgYSBjaGFuZ2luZyBE VUlEIChEVUlELUxMVCkgb24gZWFjaCBjbGllbnQgcmVzZXQgYW5kIHRoZSBzZXJ2ZXIgYWxsb2Nh dGVkIGEgbmV3IFBEIHRvIGVhY2ggY2xpZW50ISAgTm90IHRvIG1lbnRpb24gaG93IGRvZXMgYW4g YWRtaW4gb2YgdGhlIERIQ1B2NiBzZXJ2ZXIgaWRlbnRpZnkgREhDUHY2IGNsaWVudHMgaWYgdGhl IERVSUQgY2hhbmdlZCBvbiBlYWNoIGNsaWVudCByZXNldD8gICAgRm9yIHRoZSBJUHY2IENFIHJv dXRlciBSRkMgNjIwNCwgYmVjYXVzZSB0aGUgZG9jdW1lbnQgbGltaXRzIGl0c2VsZiB0byBvbmUg ZGV2aWNlIGluIHRoZSBJUHY2IENFIHJvdXRlciwgd2UgY291bGQgIHRpZ2h0ZW4gdGhlIGxhbmd1 YWdlIHRvIGZvcmNlIHRoZSBkZXZpY2UgdG8ga2VlcCB0aGUgRFVJRCBwZXJzaXN0ZW50LiAgIFNl ZSBidWxsZXQgVy02IGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyMDQNCg0KIA0K DQpSZWdhcmRzLA0KDQogDQoNCkhlbWFudA0KDQogDQoNCkZyb206IHBlcmwtbGlzdCBbbWFpbHRv OnBlcmwtbGlzdEBuZXR3b3JrMS5uZXRdIA0KDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIw MTIgMTI6MjAgUE0NCg0KVG86IEhlbWFudCBTaW5naCAoc2hlbWFudCkNCg0KQ2M6IGRoYyBXRzsg V29qY2llY2ggRGVjICh3ZGVjKQ0KDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJRVRGODMgZGhjd2cg YWdlbmRhIGl0ZW1zDQoNCiANCg0KSW4gY2FzZSB5b3UgYXJlIGN1cmlvdXMgYWJvdXQgdGhlIG9y aWdpbmFsIDE2MCsgbWVzc2FnZSB0aHJlYWQsIGhlcmUgaXMgYSBsaW5rIHRvIGl0Og0KDQogDQoN Cmhvc3QtaWRlbnRpZmllciB3aXRoIElQdjYNCg0KaHR0cHM6Ly9saXN0cy5pc2Mub3JnL3BpcGVy bWFpbC9kaGNwLXVzZXJzLzIwMDktTWFyY2gvMDA4NDg5Lmh0bWwNCg0KIA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206ICJwZXJsLWxpc3QiIDxwZXJs LWxpc3RAbmV0d29yazEubmV0Pg0KDQpUbzogIkhlbWFudCBTaW5naCAoc2hlbWFudCkiIDxzaGVt YW50QGNpc2NvLmNvbT4NCg0KQ2M6ICJkaGMgV0ciIDxkaGN3Z0BpZXRmLm9yZz4sICJXb2pjaWVj aCBEZWMgKHdkZWMpIiA8d2RlY0BjaXNjby5jb20+DQoNClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAx NSwgMjAxMiAxMjoxMTowNCBQTQ0KDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJRVRGODMgZGhjd2cg YWdlbmRhIGl0ZW1zDQoNCkhlbWFudCwNCg0KIA0KDQpUaGlzIHN1bW1hcnksIGFmdGVyIGEgMTYw KyBwb3N0IHRocmVhZCBmcm9tIHRoZSBpc2MgbWFpbCBncm91cCBkaGNwLXVzZXJzLCBzaG91bGQg c3VtIHVwIHRoZSBuZWVkIGZvciBhIGhhcmR3YXJlIG9wdGlvbiBxdWl0ZSBuaWNlbHk6DQoNCiAN Cg0KREhDUHY2IGhvc3QtaWRlbnRpZmllciwgdGhlIE5ldmVyIEVuZGluZyBUaHJlYWQ6IEEgU3Vt bWFyeQ0KDQpodHRwczovL2xpc3RzLmlzYy5vcmcvcGlwZXJtYWlsL2RoY3AtdXNlcnMvMjAwOS1N YXJjaC8wMDg2NzguaHRtbA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KRnJvbTogIkhlbWFudCBTaW5naCAoc2hlbWFudCkiIDxzaGVtYW50QGNpc2Nv LmNvbT4NCg0KVG86ICJTaHdldGhhIEJoYW5kYXJpIChzaHdldGhhYikiIDxzaHdldGhhYkBjaXNj by5jb20+LCAiSm9obiBCcnpvem93c2tpIiA8Sm9obl9Ccnpvem93c2tpQENhYmxlLkNvbWNhc3Qu Y29tPiwgImRoYyBXRyIgPGRoY3dnQGlldGYub3JnPg0KDQpDYzogIldvamNpZWNoIERlYyAod2Rl YykiIDx3ZGVjQGNpc2NvLmNvbT4NCg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE1LCAyMDEyIDEw OjA5OjU0IEFNDQoNClN1YmplY3Q6IFJlOiBbZGhjd2ddIElFVEY4MyBkaGN3ZyBhZ2VuZGEgaXRl bXMNCg0KIA0KDQpXb2osDQoNCiANCg0KSXQgd291bGQgYmUgZ29vZCB0byBwcm92aWRlIGNvbnRl eHQgYW5kIG1vcmUgZGVzY3JpcHRpdmUgdXNlIGNhc2VzIGZvcg0KDQp0aGUgZHJhZnQtaGFsd2Fz aWEtZGhjLWRoY3B2Ni1oYXJkd2FyZS1hZGRyLW9wdC0wMS4gIFNwZWNpZmljYWxseSB3aGljaA0K DQpzZXQgb2YgU1AncyBvciBhbnkgb3RoZXIgc3RhbmRhcmRzIGJvZHkgb3V0c2lkZSBvZiB0aGUg SUVURiBoYXZlIGFza2VkDQoNCmZvciBzdWNoIHdvcms/ICBXaXRoIGFkZGl0aW9uYWwgZGF0YSwg d2UgYWxsIGNhbiBzZWUgd2hhdCBlbHNlIGNhbiBiZQ0KDQpkb25lLiAgQXQgdGhlIGxhc3QgSUVU RiwgSm9obkIgKGNvLUNoYWlyKSBzdWdnZXN0ZWQgdG8gdXNlIGENCg0KdmVuZG9yLXNwZWNpZmlj IG9wdGlvbiBhbmQgSSBhZ3JlZSB3aXRoIGhpbS4gIElQdjYgaXMgYWxyZWFkeSBkZXBsb3llZA0K DQppbiBjYWJsZSBicm9hZGJhbmQgZm9yIGR1YWwtc3RhY2sgSVAgc2VydmljZXMganVzdCBmaW5l IHdpdGggdGhlIENpc2NvDQoNCkNOUiAoREhDUHY2IHNlcnZlcikgYW5kIGJhY2tlbmQgcHJvdmlz aW9uaW5nIHN5c3RlbXMgaW4gdGhlIEJBQ0MuIFN1Y2ggYQ0KDQpkZXBsb3ltZW50IGFscmVhZHkg a25vd3MgaG93IHRvIGFzc29jaWF0ZSBhIGR1YWwtc3RhY2sgY2xpZW50LiAgDQoNCiANCg0KQSBm ZXcgb3RoZXJzIHdobyBoYXZlIHJlc3BvbmRlZCB0byBtb3ZlIHRoZQ0KDQpkcmFmdC1oYWx3YXNp YS1kaGMtZGhjcHY2LWhhcmR3YXJlLWFkZHItb3B0LTAxIGZvcndhcmQgaW4gdGhlIERIQyBXRw0K DQpzaG91bGQgYWxzbyBhcnRpY3VsYXRlIHdoYXQgdGhlaXIgdXNlIGNhc2UgaXMgYW5kIHdoYXQg aXMgdGhlDQoNCnNob3dzdG9wcGVyIHByb2JsZW0gdGhleSBoYXZlIHRoYXQgdGhlIElFVEYgc2hv dWxkIGxvb2sgaW50byB0aGlzIHdvcmsuDQoNCiANCg0KIA0KDQpUaGFua3MsDQoNCiANCg0KSGVt YW50DQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogZGhjd2ctYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0K DQpPZiBTaHdldGhhIEJoYW5kYXJpIChzaHdldGhhYikNCg0KU2VudDogVHVlc2RheSwgTWFyY2gg MTMsIDIwMTIgMTI6MTQgQU0NCg0KVG86IEJyem96b3dza2ksIEpvaG47IGRoYyBXRw0KDQpDYzog U3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKQ0KDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJRVRGODMg ZGhjd2cgYWdlbmRhIGl0ZW1zDQoNCiANCg0KSGkgSm9obiwNCg0KIA0KDQpSZXF1ZXN0IHlvdSB0 byBhbGxvY2F0ZSBzbG90cyBmb3IgdGhlIGZvbGxvd2luZyAzIGRyYWZ0czoNCg0KIA0KDQpGb2xs b3dpbmcgMiB3ZSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgYW5kIHBvbGwgZm9yIHdnIGFkb3B0aW9u DQoNCjEuIGRyYWZ0LWJoYW5kYXJpLWRoYy1jbGFzcy1iYXNlZC1wcmVmaXgtMDEudHh0IC0gKDEw IG1pbnMpIFdlIGhhZA0KDQpwcmVzZW50ZWQNCg0KdGhpcyBpbiBUYWl3YW4gYW5kIHRoZXJlIHdh cyBjb25zaWRlcmFibGUgaW50ZXJlc3QgaW4gd2cuIFdlIHdvdWxkIGxpa2UNCg0KdG8NCg0KcHJl c2VudCBob3cgdGhpcyBuZXcgb3B0aW9uIGhlbHBzIGluICJQcmVmaXggY29sb3JpbmciIHVzZWNh c2UgaW4gbW9iaWxlDQoNCm5ldHdvcmtzICAgDQoNCjIuIGRyYWZ0LWhhbHdhc2lhLWRoYy1kaGNw djYtaGFyZHdhcmUtYWRkci1vcHQtMDEgKDUgbWlucyktIFdlIGhhdmUNCg0KYWRkcmVzc2VkIHRo ZSByZXZpZXcgY29tbWVudHMgcmVjZWl2ZWQuIFRoZXJlIHdhcyBpbnRlcmVzdCBleHByZXNzZWQg aW4NCg0Kd2cNCg0KYW5kIHRoZSBtYWlsZXIgZm9yIHRoaXMgdG8gYmUgYWRvcHRlZCBhcyBhIHdn IGRyYWZ0Lg0KDQogDQoNCkF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1kaGMtY2xpZW50LWlkLTAyICg1 IG1pbnMpIGhhdmUgcmVxdWVzdGVkIG1lIHRvDQoNCnByZXNlbnQNCg0KdGhlIHN0YXR1cyBvZiB0 aGlzIGRyYWZ0IGFuZCBjaGVjayBmb3IgV0cgbGFzdCBjYWxsIGFzIHRoZXJlIGFyZSBubw0KDQpw ZW5kaW5nDQoNCnJldmlldyBjb21tZW50cy4NCg0KIA0KDQpUaGFua3MsDQoNClNod2V0aGENCg0K IA0KDQogDQoNCk9uIDMvMTMvMTIgMTI6MTggQU0sICJCcnpvem93c2tpLCBKb2huIg0KDQo8Sm9o bl9Ccnpvem93c2tpQENhYmxlLkNvbWNhc3QuY29tPg0KDQp3cm90ZToNCg0KIA0KDQo+IEZvbGtz LA0KDQo+IA0KDQo+IEZvciB0aG9zZSBvZiB5b3UgdGhhdCBoYXZlIG5ldyBvciBleGlzdGluZyB3 b3JrIHRoYXQgcmVxdWlyZXMgdGltZQ0KDQpkdXJpbmcNCg0KPiB0aGUgSUVURjgzIGRoY3dnICBt ZWV0aW5nIHBsZWFzZSBzZW5kIHVzIG1haWwgd2l0aCB5b3VyIHJlcXVlc3QuDQoNCj4gDQoNCj4g SWYgeW91IGhhdmUgYWxyZWFkeSBzZW50IHVzIHlvdXIgcmVxdWVzdCBwbGVhc2UgY29uZmlybSB5 b3VyIHJlcXVlc3QsDQoNCj4gYXBvbG9naWVzIGZvciBhbnkgaW5jb252ZW5pZW5jZS4NCg0KPiAN Cg0KPiBUaGFuayB5b3UsDQoNCj4gDQoNCj4gSm9obg0KDQo+IA0KDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gZGhjd2cgbWFpbGluZyBsaXN0 DQoNCj4gZGhjd2dAaWV0Zi5vcmcNCg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RoY3dnDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KZGhjd2cgbWFpbGluZyBsaXN0DQoNCmRoY3dnQGlldGYub3JnDQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KZGhjd2cgbWFpbGluZyBsaXN0 DQoNCmRoY3dnQGlldGYub3JnDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGhjd2cNCg0KIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCmRoY3dnIG1haWxpbmcgbGlzdA0KDQpkaGN3Z0BpZXRmLm9yZw0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQoNCiANCg0KIA0KDQo= ------_=_NextPart_001_01CD02DD.E0E018B8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQs IGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlBsZWFzZSBu b3RlIHRoYXQgb25lIHJlYXNvbiBJIGhhdmUgaGVhcmQgd2h5IHRoZSBEVUlEIHdhcyBpbnRyb2R1 Y2VkIGluIERIQ1B2NiBpcyBhbHNvIGluY2x1ZGVkIGluIHRoZSBmb2xsb3dpbmcgdGV4dCBmb3Ig UkZDIDMzMTUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+W2EgZGV2aWNlJ3MgRFVJRCBzaG91bGQgbm90IGNoYW5nZSBhcyBhIHJlc3Vs dCBvZiBhIGNoYW5nZSBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiB0aGUgZGV2aWNlJ3Mg bmV0d29yayBoYXJkd2FyZS5dPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+SG93IG11Y2ggdG8gYWRtaW5zIG9mIG5ldHdvcmtzIGFuZCBE SENQdjYgc2VydmVyIGNhcmUgYWJvdXQgY2hhbmdlZCBOSUMgY2FyZCBpbiBhIFBDIHRoYXQgaXMg YWxzbyBhIERIQ1B2NiBjbGllbnQ/IMKgV2h5IG5vdCBqdXN0IGNhbGwgb25lJ3MgYWRtaW4gdG8g cmVwb3J0IGEgY2hhbmdlZCBOSUMgY2FyZC7CoCBMYXB0b3BzIG5vdyBoYXZlIGJ1aWx0LWluIHdp cmVsZXNzIGFuZCB0aGVyZSBpcyBubyBFdGhlcm5ldCBoYXJkd2FyZSBjaGFuZ2luZyBvbiBzdWNo IG1hY2hpbmVzLsKgIElmIGZvbGtzIGFyZSB3aWxsaW5nIHRvIGdpdmUgdXAgdGhlIOKAnGNoYW5n ZWQgTklDIGNhcmTigJ0gcmVxdWlyZW1lbnQsIG9uZSBjb3VsZCBkaXNwZW5zZSB3aXRoIHRoZSBE VUlELsKgwqAgSSBwcmVmZXIgb25lIGlkZW50aWZpZXIgdG8gaWRlbnRpZnkgYSBjbGllbnQgaW4g ZWl0aGVyIG9mIGhhcmR3YXJlIGFkZHJlc3Mgb3IgRFVJRCBidXQgbm90IGJvdGguwqAgVGh1cyBp ZiBmb2xrcyB3YW50IGEgaGFyZHdhcmUgYWRkcmVzcywgdGhlbiBvbmUgY291bGQgY29uc2lkZXIg ZGVwcmVjYXRpbmcgdGhlIERVSUQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+TXkgaW50ZW50IGlzIHRvIG5vdCByb2NrIHRoZSBib2F0 IGJlY2F1c2UgU1BzIGFyZSBwbGFubmluZyBvbiBESENQdjYgZGVwbG95bWVudHMgYXMgd2Ugc3Bl YWsuwqAgSG93ZXZlciwgaWYgdGhlIHByb3RvY29sIGlzIGNoYW5naW5nIGZvciBoYXJkd2FyZSBh ZGRyZXNzIGluY2x1c2lvbiB3aHkgbm90IG1ha2UgYSBjbGVhbiBjaGFuZ2UgcmF0aGVyIHRoYW4g YSBiYW5kLWFpZCB0aGF0IGhhcyBhIERIQ1B2NiBwcm90b2NvbCB0aGF0IHN1cHBvcnRzIGJvdGgg RFVJRCBhbmQgaGFyZHdhcmUgYWRkcmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQ291cmllciBOZXciJz5IZW1hbnQgPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+RnJvbTogcGVybC1saXN0IFttYWlsdG86cGVybC1saXN0QG5ldHdvcmsxLm5ldF0g PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlNlbnQ6IFRodXJzZGF5LCBNYXJj aCAxNSwgMjAxMiAyOjI0IFBNPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlRv OiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PkNjOiBkaGMgV0c7IFdvamNpZWNoIERlYyAod2RlYyk8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+U3ViamVjdDogUmU6IFtkaGN3Z10gSUVURjgzIGRoY3dnIGFnZW5kYSBp dGVtczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+SSBmdWxseSBzdXBwb3J0IGFkZGluZyB0aGUgaGFy ZHdhcmUgYWRkcmVzcyB0byB0aGUgREhDUCBtZXNzYWdlcyBob3dldmVyIHRoYXQgaGFwcGVucy4g Jm5ic3A7SWYgaXQgbWVhbnMgcmVwbGFjaW5nIHRoZSBEVUlEIHRoYXQgaXMgdmVyeSBtdWNoIGZp bmUgd2l0aCBtZS4gJm5ic3A7SW4gd2hhdGV2ZXIgc2hhcGUgb3IgZm9ybSB0aGUgaGFyZHdhcmUg YWRkcmVzcyBtYWtlcyBpdCBpbiB0aGUgcGFja2V0LCBJIHdvdWxkIGJlIHZlcnkgaGFwcHkgdG8g c2VlIGl0IHRoZXJlIGFzIGl0IHdvdWxkIG1ha2UgaW1wbGVtZW50YXRpb24gb2YgcGFyaXR5IGJl dHdlZW4gREhDUHY0IGFuZCBESENQdjYgY2xpZW50cyBNVUNIIHNpbXBsZXIgYXMgd2UgbW92ZSBp bnRvIHRoZSBkdWFsLXN0YWNrIHBlcmlvZCBvZiB0aGUgSW50ZXJuZXQuICZuYnNwO0N1cnJlbnRs eSBpdCBpcyB2ZXJ5IG5lYXJseSBpbXBvc3NpYmxlIHRvIGhhdmUgcGFyaXR5IHdpdGhvdXQgc29t ZSBzcGVjaWFsIHZlbmRvciBlcXVpcG1lbnQgb2Ygc29tZSBraW5kLCBhcyBmYXIgYXMgSSBjYW4g dGVsbCAoSVNDIERIQ1AgNC4yLjMpIG9uIGEgY29uc2lzdGVudCBiYXNpcy4gTm90IGFsbCBjbGll bnRzIHVzZSB0aGUgaGFyZHdhcmUgYWRkcmVzcyB0byBnZW5lcmF0ZSB0aGUgRFVJRCBwZXIgUkZD LiBXaXRob3V0IHRoZSBoYXJkd2FyZSBhZGRyZXNzIHRoZXJlLCB0ZWxsaW5nIHdoaWNoIERIQ1B2 NCBjbGllbnQgbWF0Y2hlcyB3aGljaCBESENQdjYgY2xpZW50IGlzIG5vdCBwb3NzaWJsZS48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+RnJvbTogJnF1b3Q7SGVtYW50 IFNpbmdoIChzaGVtYW50KSZxdW90OyAmbHQ7c2hlbWFudEBjaXNjby5jb20mZ3Q7PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlRvOiAmcXVvdDtwZXJsLWxpc3QmcXVvdDsgJmx0 O3BlcmwtbGlzdEBuZXR3b3JrMS5uZXQmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PkNjOiAmcXVvdDtkaGMgV0cmcXVvdDsgJmx0O2RoY3dnQGlldGYub3JnJmd0OywgJnF1 b3Q7V29qY2llY2ggRGVjICh3ZGVjKSZxdW90OyAmbHQ7d2RlY0BjaXNjby5jb20mZ3Q7PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwg MjAxMiAxOjIyOjM5IFBNPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlN1Ympl Y3Q6IFJFOiBbZGhjd2ddIElFVEY4MyBkaGN3ZyBhZ2VuZGEgaXRlbXM8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UaGFua3Mg bXVjaCBmb3IgdGhlIFVSTCB0byB0aGUgZGV0YWlscy4mbmJzcDsgJm5ic3A7V29q4oCZcyBkb2N1 bWVudHMgbWVudGlvbnMgYSBzbGlnaHRseSBkaWZmZXJlbnQgcHJvYmxlbSB3aGljaCBpcyBob3cg ZG9lcyBhbiBTUCBmaW5kIGR1YWwtc3RhY2sgREhDUHY0IGFuZCBESENQdjYgY2xpZW50cy4mbmJz cDsmbmJzcDsgVG8gdGhhdCBwcm9ibGVtLCBJIGFscmVhZHkgcG9pbnRlZCB0byBwcm9kdWN0cyBh bmQgY2FibGUgZGVwbG95bWVudCB0aGF0IGFscmVhZHkga25vd3MgaG93IHRvIElEIGNsaWVudHMg dGhhdCBhcmUgZHVhbC1zdGFjayBpbiB0aGUgU1AgbmV0d29yay4mbmJzcDsmbmJzcDsmbmJzcDsg VGhlIG5ldyBsaW5rcyBzZW50IHRvIG1lIGFyZSBtb3JlIG9mIGEgRW50ZXJwcmlzZSBkZXBsb3lt ZW50LiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5i c3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkkgcHJlZmVyIGNsZWFuZXIg c29sdXRpb25zIGJ1dCBteSB0aG91Z2h0IHdpbGwgbm90IGJlIGxpa2VkIGJ5IERIQ1B2NiBzZXJ2 ZXIgdmVuZG9ycyBub3IgcmVsYXkgdmVuZG9ycy4mbmJzcDsmbmJzcDsgRm9yZ2V0IGFkZGluZyBh IG5ldyBoYXJkd2FyZSBvcHRpb24gdG8gREhDUHY2LiZuYnNwOyBESENQdjYgbWFkZSBhIGZ1bmRh bWVudGFsIG1pc3Rha2UgZXhjbHVkaW5nIHRoZSBoYXJkd2FyZSBhZGRyZXNzIGZyb20gdGhlIHBy b3RvY29sLiZuYnNwOyZuYnNwOyBTbyBhY2sgdGhhdCBtaXN0YWtlLCByZW1vdmUgdGhlIERVSUQg ZnJvbSB0aGUgcHJvdG9jb2wsIGFuZCByZXBsYWNlIHRoZSBEVUlEIHdpdGggdGhlIGNoYWRkciBv ZiBESENQdjQuJm5ic3A7Jm5ic3A7IE1vc3QgaG9zdHMgaW1wbGVtZW50ZWQgYSBjaGFuZ2luZyBE VUlEIChEVUlELUxMVCkgb24gZWFjaCBjbGllbnQgcmVzZXQgYW5kIHRoZSBzZXJ2ZXIgYWxsb2Nh dGVkIGEgbmV3IFBEIHRvIGVhY2ggY2xpZW50ISZuYnNwOyBOb3QgdG8gbWVudGlvbiBob3cgZG9l cyBhbiBhZG1pbiBvZiB0aGUgREhDUHY2IHNlcnZlciBpZGVudGlmeSBESENQdjYgY2xpZW50cyBp ZiB0aGUgRFVJRCBjaGFuZ2VkIG9uIGVhY2ggY2xpZW50IHJlc2V0PyAmbmJzcDsmbmJzcDsmbmJz cDtGb3IgdGhlIElQdjYgQ0Ugcm91dGVyIFJGQyA2MjA0LCBiZWNhdXNlIHRoZSBkb2N1bWVudCBs aW1pdHMgaXRzZWxmIHRvIG9uZSBkZXZpY2UgaW4gdGhlIElQdjYgQ0Ugcm91dGVyLCB3ZSBjb3Vs ZCAmbmJzcDt0aWdodGVuIHRoZSBsYW5ndWFnZSB0byBmb3JjZSB0aGUgZGV2aWNlIHRvIGtlZXAg dGhlIERVSUQgcGVyc2lzdGVudC4gJm5ic3A7Jm5ic3A7U2VlIGJ1bGxldCBXLTYgaW4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjIwNDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+UmVnYXJk cyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkhlbWFudDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+RnJv bTogcGVybC1saXN0IFttYWlsdG86cGVybC1saXN0QG5ldHdvcmsxLm5ldF0gPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxMiAx MjoyMCBQTTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UbzogSGVtYW50IFNp bmdoIChzaGVtYW50KTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5DYzogZGhj IFdHOyBXb2pjaWVjaCBEZWMgKHdkZWMpPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PlN1YmplY3Q6IFJlOiBbZGhjd2ddIElFVEY4MyBkaGN3ZyBhZ2VuZGEgaXRlbXM8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PkluIGNhc2UgeW91IGFyZSBjdXJpb3VzIGFib3V0IHRoZSBvcmlnaW5h bCAxNjArIG1lc3NhZ2UgdGhyZWFkLCBoZXJlIGlzIGEgbGluayB0byBpdDo8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0Pmhvc3QtaWRlbnRpZmllciB3aXRoIElQdjY8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+aHR0cHM6Ly9saXN0cy5pc2Mub3JnL3BpcGVybWFpbC9kaGNwLXVzZXJz LzIwMDktTWFyY2gvMDA4NDg5Lmh0bWw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+RnJvbTogJnF1b3Q7cGVybC1saXN0JnF1b3Q7ICZsdDtwZXJsLWxpc3RAbmV0d29y azEubmV0Jmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UbzogJnF1b3Q7 SGVtYW50IFNpbmdoIChzaGVtYW50KSZxdW90OyAmbHQ7c2hlbWFudEBjaXNjby5jb20mZ3Q7PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkNjOiAmcXVvdDtkaGMgV0cmcXVvdDsg Jmx0O2RoY3dnQGlldGYub3JnJmd0OywgJnF1b3Q7V29qY2llY2ggRGVjICh3ZGVjKSZxdW90OyAm bHQ7d2RlY0BjaXNjby5jb20mZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PlNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxMiAxMjoxMTowNCBQTTxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD5TdWJqZWN0OiBSZTogW2RoY3dnXSBJRVRGODMgZGhjd2cg YWdlbmRhIGl0ZW1zPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkhlbWFudCw8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlRoaXMgc3VtbWFyeSwgYWZ0ZXIgYSAxNjArIHBvc3QgdGhy ZWFkIGZyb20gdGhlIGlzYyBtYWlsIGdyb3VwIGRoY3AtdXNlcnMsIHNob3VsZCBzdW0gdXAgdGhl IG5lZWQgZm9yIGEgaGFyZHdhcmUgb3B0aW9uIHF1aXRlIG5pY2VseTo8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PkRIQ1B2NiBob3N0LWlkZW50aWZpZXIsIHRoZSBOZXZlciBFbmRpbmcgVGhyZWFkOiBB IFN1bW1hcnk8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+aHR0cHM6Ly9saXN0 cy5pc2Mub3JnL3BpcGVybWFpbC9kaGNwLXVzZXJzLzIwMDktTWFyY2gvMDA4Njc4Lmh0bWw8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+RnJvbTogJnF1b3Q7SGVtYW50 IFNpbmdoIChzaGVtYW50KSZxdW90OyAmbHQ7c2hlbWFudEBjaXNjby5jb20mZ3Q7PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlRvOiAmcXVvdDtTaHdldGhhIEJoYW5kYXJpIChz aHdldGhhYikmcXVvdDsgJmx0O3Nod2V0aGFiQGNpc2NvLmNvbSZndDssICZxdW90O0pvaG4gQnJ6 b3pvd3NraSZxdW90OyAmbHQ7Sm9obl9Ccnpvem93c2tpQENhYmxlLkNvbWNhc3QuY29tJmd0Oywg JnF1b3Q7ZGhjIFdHJnF1b3Q7ICZsdDtkaGN3Z0BpZXRmLm9yZyZndDs8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Q2M6ICZxdW90O1dvamNpZWNoIERlYyAod2RlYykmcXVvdDsg Jmx0O3dkZWNAY2lzY28uY29tJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD5TZW50OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIwMTIgMTA6MDk6NTQgQU08bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+U3ViamVjdDogUmU6IFtkaGN3Z10gSUVURjgzIGRoY3dn IGFnZW5kYSBpdGVtczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZu YnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+V29qLDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+SXQgd291bGQgYmUgZ29vZCB0byBwcm92aWRlIGNvbnRleHQgYW5kIG1vcmUgZGVzY3Jp cHRpdmUgdXNlIGNhc2VzIGZvcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD50 aGUgZHJhZnQtaGFsd2FzaWEtZGhjLWRoY3B2Ni1oYXJkd2FyZS1hZGRyLW9wdC0wMS4gJm5ic3A7 U3BlY2lmaWNhbGx5IHdoaWNoPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PnNl dCBvZiBTUCdzIG9yIGFueSBvdGhlciBzdGFuZGFyZHMgYm9keSBvdXRzaWRlIG9mIHRoZSBJRVRG IGhhdmUgYXNrZWQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Zm9yIHN1Y2gg d29yaz8gJm5ic3A7V2l0aCBhZGRpdGlvbmFsIGRhdGEsIHdlIGFsbCBjYW4gc2VlIHdoYXQgZWxz ZSBjYW4gYmU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ZG9uZS4gJm5ic3A7 QXQgdGhlIGxhc3QgSUVURiwgSm9obkIgKGNvLUNoYWlyKSBzdWdnZXN0ZWQgdG8gdXNlIGE8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+dmVuZG9yLXNwZWNpZmljIG9wdGlvbiBh bmQgSSBhZ3JlZSB3aXRoIGhpbS4gJm5ic3A7SVB2NiBpcyBhbHJlYWR5IGRlcGxveWVkPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PmluIGNhYmxlIGJyb2FkYmFuZCBmb3IgZHVh bC1zdGFjayBJUCBzZXJ2aWNlcyBqdXN0IGZpbmUgd2l0aCB0aGUgQ2lzY288bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Q05SIChESENQdjYgc2VydmVyKSBhbmQgYmFja2VuZCBw cm92aXNpb25pbmcgc3lzdGVtcyBpbiB0aGUgQkFDQy4gU3VjaCBhPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PmRlcGxveW1lbnQgYWxyZWFkeSBrbm93cyBob3cgdG8gYXNzb2Np YXRlIGEgZHVhbC1zdGFjayBjbGllbnQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+QSBm ZXcgb3RoZXJzIHdobyBoYXZlIHJlc3BvbmRlZCB0byBtb3ZlIHRoZTxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD5kcmFmdC1oYWx3YXNpYS1kaGMtZGhjcHY2LWhhcmR3YXJlLWFk ZHItb3B0LTAxIGZvcndhcmQgaW4gdGhlIERIQyBXRzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD5zaG91bGQgYWxzbyBhcnRpY3VsYXRlIHdoYXQgdGhlaXIgdXNlIGNhc2UgaXMg YW5kIHdoYXQgaXMgdGhlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PnNob3dz dG9wcGVyIHByb2JsZW0gdGhleSBoYXZlIHRoYXQgdGhlIElFVEYgc2hvdWxkIGxvb2sgaW50byB0 aGlzIHdvcmsuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+SGVtYW50PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0Pk9mIFNod2V0aGEgQmhhbmRhcmkgKHNod2V0aGFiKTxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5TZW50OiBUdWVzZGF5LCBNYXJjaCAxMywgMjAx MiAxMjoxNCBBTTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UbzogQnJ6b3pv d3NraSwgSm9objsgZGhjIFdHPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkNj OiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PlN1YmplY3Q6IFJlOiBbZGhjd2ddIElFVEY4MyBkaGN3ZyBhZ2VuZGEgaXRlbXM8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PkhpIEpvaG4sPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5SZXF1ZXN0 IHlvdSB0byBhbGxvY2F0ZSBzbG90cyBmb3IgdGhlIGZvbGxvd2luZyAzIGRyYWZ0czo8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PkZvbGxvd2luZyAyIHdlIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBhbmQg cG9sbCBmb3Igd2cgYWRvcHRpb248bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ MS4gZHJhZnQtYmhhbmRhcmktZGhjLWNsYXNzLWJhc2VkLXByZWZpeC0wMS50eHQgLSAoMTAgbWlu cykgV2UgaGFkPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PnByZXNlbnRlZDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD50aGlzIGluIFRhaXdhbiBhbmQgdGhl cmUgd2FzIGNvbnNpZGVyYWJsZSBpbnRlcmVzdCBpbiB3Zy4gV2Ugd291bGQgbGlrZTxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD50bzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD5wcmVzZW50IGhvdyB0aGlzIG5ldyBvcHRpb24gaGVscHMgaW4gJnF1b3Q7UHJl Zml4IGNvbG9yaW5nJnF1b3Q7IHVzZWNhc2UgaW4gbW9iaWxlPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0Pm5ldHdvcmtzICZuYnNwOyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Mi4gZHJhZnQtaGFsd2FzaWEtZGhjLWRoY3B2Ni1oYXJkd2FyZS1hZGRyLW9w dC0wMSAoNSBtaW5zKS0gV2UgaGF2ZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD5hZGRyZXNzZWQgdGhlIHJldmlldyBjb21tZW50cyByZWNlaXZlZC4gVGhlcmUgd2FzIGludGVy ZXN0IGV4cHJlc3NlZCBpbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD53Zzxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5hbmQgdGhlIG1haWxlciBmb3IgdGhp cyB0byBiZSBhZG9wdGVkIGFzIGEgd2cgZHJhZnQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5BdXRo b3JzIG9mIGRyYWZ0LWlldGYtZGhjLWNsaWVudC1pZC0wMiAoNSBtaW5zKSBoYXZlIHJlcXVlc3Rl ZCBtZSB0bzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5wcmVzZW50PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PnRoZSBzdGF0dXMgb2YgdGhpcyBkcmFmdCBh bmQgY2hlY2sgZm9yIFdHIGxhc3QgY2FsbCBhcyB0aGVyZSBhcmUgbm88bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+cGVuZGluZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD5yZXZpZXcgY29tbWVudHMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UaGFua3MsPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlNod2V0aGE8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5PbiAzLzEz LzEyIDEyOjE4IEFNLCAmcXVvdDtCcnpvem93c2tpLCBKb2huJnF1b3Q7PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZsdDtKb2huX0Jyem96b3dza2lAQ2FibGUuQ29tY2FzdC5j b20mZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pndyb3RlOjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyBGb2xrcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBGb3Ig dGhvc2Ugb2YgeW91IHRoYXQgaGF2ZSBuZXcgb3IgZXhpc3Rpbmcgd29yayB0aGF0IHJlcXVpcmVz IHRpbWU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ZHVyaW5nPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgdGhlIElFVEY4MyBkaGN3ZyAmbmJzcDtt ZWV0aW5nIHBsZWFzZSBzZW5kIHVzIG1haWwgd2l0aCB5b3VyIHJlcXVlc3QuPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsgSWYgeW91IGhhdmUgYWxyZWFkeSBzZW50IHVzIHlvdXIgcmVxdWVzdCBw bGVhc2UgY29uZmlybSB5b3VyIHJlcXVlc3QsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgYXBvbG9naWVzIGZvciBhbnkgaW5jb252ZW5pZW5jZS48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyBUaGFuayB5b3UsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgSm9objxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg ZGhjd2cgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgZGhjd2dAaWV0Zi5vcmc8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5kaGN3ZyBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ZGhjd2dAaWV0Zi5vcmc8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaGN3ZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD5kaGN3ZyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+ZGhjd2dAaWV0Zi5vcmc8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3 ZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mbmJzcDs8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PmRoY3dnIG1haWxpbmcgbGlzdDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5kaGN3Z0BpZXRmLm9yZzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RoY3dnPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZuYnNw OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CD02DD.E0E018B8-- From Ted.Lemon@nominum.com Thu Mar 15 12:21:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5627121F8622 for ; Thu, 15 Mar 2012 12:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8vPifFtleQU for ; Thu, 15 Mar 2012 12:20:58 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 0221D21F861D for ; Thu, 15 Mar 2012 12:20:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT2JBBVUFn8DRh9M6TuEf2waIUoN9NYCx@postini.com; Thu, 15 Mar 2012 12:20:38 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0370E1B8311 for ; Thu, 15 Mar 2012 12:20:37 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id ED24E19005C; Thu, 15 Mar 2012 12:20:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 12:20:36 -0700 From: Ted Lemon To: perl-list Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAAyhgA= Date: Thu, 15 Mar 2012 19:20:34 +0000 Message-ID: <8767518B-0EB7-4C9C-9B22-70E7B706EDFC@nominum.com> References: <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> In-Reply-To: <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8767518B0EB74C9C9B2270E7B706EDFCnominumcom_" MIME-Version: 1.0 Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:21:00 -0000 --_000_8767518B0EB74C9C9B2270E7B706EDFCnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 12:19 PM, perl-list > wrote: In case you are curious about the original 160+ message thread, here is a l= ink to it: host-identifier with IPv6 https://lists.isc.org/pipermail/dhcp-users/2009-March/008489.html It's probably worth noting that Cisco has, unfortunately, patented the orig= inal and ingenious technique whereby the relay agent captures the layer 2 s= ource address from which it receives a client message, and records it in th= e relay agent options portion of the relayed message. This argues, as you say, for having the client include the information, sin= ce I don't think Cisco has patented that. I personally prefer Cisco's inge= nious and patented solution, but it's probably best not to use it, so as to= avoid future patent trolling. (In case any IP lawyers troll this message later, I'd like to be clear that= I am being sarcastic when I call this technique ingenious. Were I speaki= ng literally rather than sarcastically, I would describe it as blazingly ob= vious to any practitioner in the field.) --_000_8767518B0EB74C9C9B2270E7B706EDFCnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 12:19 PM, perl-list <perl-list@network1.net> wrote:
In case you are curious about the original 160+ message thread, here is a= link to it:

host-identifier with IPv6=

It's probably worth noting that Cisco has, unfortunately, patented the= original and ingenious technique whereby the relay agent captures the laye= r 2 source address from which it receives a client message, and records it = in the relay agent options portion of the relayed message.

This argues, as you say, for having the client include the information= , since I don't think Cisco has patented that.  I personally prefer Ci= sco's ingenious and patented solution, but it's probably best not to use it= , so as to avoid future patent trolling.

(In case any IP lawyers troll this message later, I'd like to be clear= that I am being sarcastic when I call this technique ingenious.   Wer= e I speaking literally rather than sarcastically, I would describe it as bl= azingly obvious to any practitioner in the field.)

--_000_8767518B0EB74C9C9B2270E7B706EDFCnominumcom_-- From Ted.Lemon@nominum.com Thu Mar 15 12:23:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C0A21F8622 for ; Thu, 15 Mar 2012 12:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCw5znYm6VAB for ; Thu, 15 Mar 2012 12:23:40 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1E27421F861D for ; Thu, 15 Mar 2012 12:23:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT2JBu3Cnltfc9KYTOZ5r0Ki4TnNuZOq5@postini.com; Thu, 15 Mar 2012 12:23:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8AE001B8311 for ; Thu, 15 Mar 2012 12:23:36 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 80CF719005C; Thu, 15 Mar 2012 12:23:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 12:23:36 -0700 From: Ted Lemon To: "Hemant Singh (shemant)" Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAARlICAACHKgA== Date: Thu, 15 Mar 2012 19:23:35 +0000 Message-ID: References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_A0317835EDF54CE19FC284BE90DD018Bnominumcom_" MIME-Version: 1.0 Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:23:41 -0000 --_000_A0317835EDF54CE19FC284BE90DD018Bnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 1:22 PM, Hemant Singh (shemant) > wrote: Most hosts implemented a changing DUID (DUID-LLT) on each client reset and = the server allocated a new PD to each client! Such hosts do not have DHCPv6 clients: the spec expressly forbids this beha= vior. They have something that implements a DHCPv6-like configuration pro= tocol, but it is not DHCPv6. The hardware address is an extremely poor choice for client identifier. D= o we really need to have yet another interminable debate about this? --_000_A0317835EDF54CE19FC284BE90DD018Bnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <223D96816281F14DAE0AEAEADD563E0A@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 1:22 PM, Hemant Singh (shemant) <shemant@cisco.com> wrote:
Most hosts implemented a changing DUID (DUID-LLT) on each client reset and the = server allocated a new PD to each client! 

Such hosts do not have DHCPv6 clients: the spec expressly forbids this= behavior.   They have something that implements a DHCPv6-like configu= ration protocol, but it is not DHCPv6.

The hardware address is an extremely poor choice for client identifier= .   Do we really need to have yet another interminable debate about th= is?

--_000_A0317835EDF54CE19FC284BE90DD018Bnominumcom_-- From dankney@network1.net Thu Mar 15 12:27:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D38F21F84A2 for ; Thu, 15 Mar 2012 12:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoaVHsJB-QmI for ; Thu, 15 Mar 2012 12:27:44 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7205C21F849B for ; Thu, 15 Mar 2012 12:27:44 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 4DE1454293C; Thu, 15 Mar 2012 15:27:43 -0400 (EDT) Date: Thu, 15 Mar 2012 15:27:43 -0400 (EDT) From: perl-list To: Ted Lemon Message-ID: <77df98dc-2430-439c-9f8f-f6e2abb13939@zimbra.network1.net> In-Reply-To: <8767518B-0EB7-4C9C-9B22-70E7B706EDFC@nominum.com> Content-Type: multipart/alternative; boundary="=_bd09880d-ede1-4559-80b4-c9d10c9095b0" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:27:45 -0000 --=_bd09880d-ede1-4559-80b4-c9d10c9095b0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Oh boy - yes a patented solution would not work very well unless it can be guaranteed that one will ONLY run into Cisco gear in the field (which it most assuredly cannot). ----- Original Message ----- > From: "Ted Lemon" > To: "perl-list" > Cc: "Hemant Singh (shemant)" , "dhc WG" > , "Wojciech Dec (wdec)" > Sent: Thursday, March 15, 2012 3:20:34 PM > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > On Mar 15, 2012, at 12:19 PM, perl-list < perl-list@network1.net > > wrote: > > In case you are curious about the original 160+ message thread, > > here > > is a link to it: > > > host-identifier with IPv6 > > > https://lists.isc.org/pipermail/dhcp-users/2009-March/008489.html > > It's probably worth noting that Cisco has, unfortunately, patented > the original and ingenious technique whereby the relay agent > captures the layer 2 source address from which it receives a client > message, and records it in the relay agent options portion of the > relayed message. > This argues, as you say, for having the client include the > information, since I don't think Cisco has patented that. I > personally prefer Cisco's ingenious and patented solution, but it's > probably best not to use it, so as to avoid future patent trolling. > (In case any IP lawyers troll this message later, I'd like to be > clear that I am being sarcastic when I call this technique > ingenious. Were I speaking literally rather than sarcastically, I > would describe it as blazingly obvious to any practitioner in the > field.) --=_bd09880d-ede1-4559-80b4-c9d10c9095b0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>Oh = boy - yes a patented solution would not work very well unless it can be gua= ranteed that one will ONLY run into Cisco gear in the field (which it most = assuredly cannot).


From: "Ted Lemon"= <Ted.Lemon@nominum.com>
To: "perl-list" <perl-list@netw= ork1.net>
Cc: "Hemant Singh (shemant)" <shemant@cisco.com&g= t;, "dhc WG" <dhcwg@ietf.org>, "Wojciech Dec (wdec)" <wdec@cisco.c= om>
Sent: Thursday, March 15, 2012 3:20:34 PM
Subject: <= /b>Re: [dhcwg] IETF83 dhcwg agenda items

On Mar 15, 2012, at 12:19 PM, perl-list <perl-list@network1.net> wrote:
In case you are curious about the original 160+ message thread, here is a lin= k to it:

host-identifier with IPv6=

It's probably worth noting that Cisco has, unfortunately, patented the= original and ingenious technique whereby the relay agent captures the laye= r 2 source address from which it receives a client message, and records it = in the relay agent options portion of the relayed message.

This argues, as you say, for having the client include the information= , since I don't think Cisco has patented that.  I personally prefer Ci= sco's ingenious and patented solution, but it's probably best not to use it= , so as to avoid future patent trolling.

(In case any IP lawyers troll this message later, I'd like to be clear= that I am being sarcastic when I call this technique ingenious.   Wer= e I speaking literally rather than sarcastically, I would describe it as bl= azingly obvious to any practitioner in the field.)


--=_bd09880d-ede1-4559-80b4-c9d10c9095b0-- From Ted.Lemon@nominum.com Thu Mar 15 12:31:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DD121E800C for ; Thu, 15 Mar 2012 12:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.417 X-Spam-Level: X-Spam-Status: No, score=-106.417 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGUEyLUr5Mhq for ; Thu, 15 Mar 2012 12:31:10 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 879BB21F84E2 for ; Thu, 15 Mar 2012 12:31:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT2JDftPiYG7JDKE31ohO83b6r4TUys4o@postini.com; Thu, 15 Mar 2012 12:31:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C233D1B8311 for ; Thu, 15 Mar 2012 12:31:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B9E8719005C; Thu, 15 Mar 2012 12:31:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 12:31:09 -0700 From: Ted Lemon To: perl-list Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAAyhgCAAAH/gIAAAPSA Date: Thu, 15 Mar 2012 19:31:08 +0000 Message-ID: <69D8496C-A4DB-4C6F-BB0D-17A20FCF8E0F@nominum.com> References: <77df98dc-2430-439c-9f8f-f6e2abb13939@zimbra.network1.net> In-Reply-To: <77df98dc-2430-439c-9f8f-f6e2abb13939@zimbra.network1.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_69D8496CA4DB4C6FBB0D17A20FCF8E0Fnominumcom_" MIME-Version: 1.0 Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:31:11 -0000 --_000_69D8496CA4DB4C6FBB0D17A20FCF8E0Fnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 3:27 PM, perl-list > wrote: Oh boy - yes a patented solution would not work very well unless it can be = guaranteed that one will ONLY run into Cisco gear in the field (which it mo= st assuredly cannot). Cisco's offered the patent under FRAND terms, but you never know what might= happen going forward. --_000_69D8496CA4DB4C6FBB0D17A20FCF8E0Fnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5E8FD8F21D44704093ACB04063F9CD3E@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 3:27 PM, perl-list <perl-list@network1.net> wrote:
Oh boy - yes a patented solution would not work very well unless it can be gu= aranteed that one will ONLY run into Cisco gear in the field (which it most= assuredly cannot).

Cisco's offered the patent under FRAND terms, but you never know what = might happen going forward.

--_000_69D8496CA4DB4C6FBB0D17A20FCF8E0Fnominumcom_-- From SRS0=BBtV=BW=WPI.EDU=cra@srs.wpi.edu Thu Mar 15 12:41:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FC221E8015 for ; Thu, 15 Mar 2012 12:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfu7iQxhWa6l for ; Thu, 15 Mar 2012 12:41:51 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id D4E9621E800C for ; Thu, 15 Mar 2012 12:41:50 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q2FJfn38003162; Thu, 15 Mar 2012 15:41:49 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q2FJfn38003162 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1331840509; bh=D5sW/waZlm97BB9+XGHuaYezkB49TyGHDNMYLiUEN1U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=gb8XlXReGtRTkpWx6gFl6NlSzQnKZ7X4aCagPm8cAL57Ia8DAWdUeFezQSA6RuCb9 ZLxt2HtRwoEIIKL70gzl3pzUtloGKwLBcRT0Q+/XrdwZE8MCBiqhuQSIFDFSkQaWTO JVFhjY3V7kGrvqwoQRpPoOxLrAsK0xtpQgPReE28= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q2FJfnqJ003159; Thu, 15 Mar 2012 15:41:49 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q2FJfl8r023489; Thu, 15 Mar 2012 15:41:48 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id q2FJflLG008510; Thu, 15 Mar 2012 15:41:47 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id q2FJflX4008509; Thu, 15 Mar 2012 15:41:47 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 15 Mar 2012 15:41:47 -0400 From: Chuck Anderson To: Ted Lemon Message-ID: <20120315194147.GO24733@angus.ind.WPI.EDU> Mail-Followup-To: Ted Lemon , perl-list , dhc WG , "Wojciech Dec (wdec)" References: <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <8767518B-0EB7-4C9C-9B22-70E7B706EDFC@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8767518B-0EB7-4C9C-9B22-70E7B706EDFC@nominum.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:43:58 -0000 On Thu, Mar 15, 2012 at 07:20:34PM +0000, Ted Lemon wrote: > It's probably worth noting that Cisco has, unfortunately, patented > the original and ingenious technique whereby the relay agent > captures the layer 2 source address from which it receives a client > message, and records it in the relay agent options portion of the > relayed message. Which patent is it? There may be documented prior art here. From shemant@cisco.com Thu Mar 15 12:47:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6658A21E802D for ; Thu, 15 Mar 2012 12:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.016 X-Spam-Level: X-Spam-Status: No, score=-10.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hf2izinMPkZP for ; Thu, 15 Mar 2012 12:47:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B1BEE21E802C for ; Thu, 15 Mar 2012 12:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=857; q=dns/txt; s=iport; t=1331840825; x=1333050425; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nKEWO1aC+217Or+zTogmyvcur97fHtYT5sGOf6fYFu8=; b=Bg8+E/qbErnxN4p0+jdwltj/63hObQquWC8DsPZFFyxOxch8oGBqznQ8 7PXNp7G/+1tMRK5u+2OLAS7m0H0/MXt6To+ZIPrhw8sVzZx1hgnAFTNHT 2Mr9eSY2wUQJ3v/fzv3fF9G9HBc/x3JKPYKQcutTNbqKhrjvBeHEdD2se Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK5GYk+tJXG//2dsb2JhbABDDrYcgQeCCQEBAQQBAQEPAR0KNAsMBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggah2gLmnSfBASQJGMEiFebSYFogi9V X-IronPort-AV: E=Sophos;i="4.73,592,1325462400"; d="scan'208";a="66786525" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 15 Mar 2012 19:47:05 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2FJl5Ah029800; Thu, 15 Mar 2012 19:47:05 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 14:47:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Mar 2012 14:47:03 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1E55@XMB-RCD-109.cisco.com> In-Reply-To: <20120315194147.GO24733@angus.ind.WPI.EDU> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: Ac0C4/ssLD5yWZj8Sv6Erpg5A48G1QAAGRxQ References: <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net><8767518B-0EB7-4C9C-9B22-70E7B706EDFC@nominum.com> <20120315194147.GO24733@angus.ind.WPI.EDU> From: "Hemant Singh (shemant)" To: "Chuck Anderson" , "Ted Lemon" X-OriginalArrivalTime: 15 Mar 2012 19:47:05.0310 (UTC) FILETIME=[6624CFE0:01CD02E4] Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:47:06 -0000 https://datatracker.ietf.org/ipr/1710/ Hemant -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Chuck Anderson Sent: Thursday, March 15, 2012 3:42 PM To: Ted Lemon Cc: dhc WG; Wojciech Dec (wdec) Subject: Re: [dhcwg] IETF83 dhcwg agenda items On Thu, Mar 15, 2012 at 07:20:34PM +0000, Ted Lemon wrote: > It's probably worth noting that Cisco has, unfortunately, patented > the original and ingenious technique whereby the relay agent > captures the layer 2 source address from which it receives a client > message, and records it in the relay agent options portion of the > relayed message. Which patent is it? There may be documented prior art here. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Thu Mar 15 12:47:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0049121F8552 for ; Thu, 15 Mar 2012 12:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.42 X-Spam-Level: X-Spam-Status: No, score=-106.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAkPKPZF6nL9 for ; Thu, 15 Mar 2012 12:47:22 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 30C7821F852B for ; Thu, 15 Mar 2012 12:47:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT2JHSYlGYqzFplNV40CuC7du+IcImCQf@postini.com; Thu, 15 Mar 2012 12:47:22 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 349D11B82ED for ; Thu, 15 Mar 2012 12:47:21 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 24E1919005C; Thu, 15 Mar 2012 12:47:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 12:47:21 -0700 From: Ted Lemon To: Chuck Anderson Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAAyhgCAAAXugIAAAY0A Date: Thu, 15 Mar 2012 19:47:20 +0000 Message-ID: References: <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <8767518B-0EB7-4C9C-9B22-70E7B706EDFC@nominum.com> <20120315194147.GO24733@angus.ind.WPI.EDU> In-Reply-To: <20120315194147.GO24733@angus.ind.WPI.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_F3911B27B0C44AB180279D410247771Dnominumcom_" MIME-Version: 1.0 Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:47:23 -0000 --_000_F3911B27B0C44AB180279D410247771Dnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 3:41 PM, Chuck Anderson > wrote: Which patent is it? There may be documented prior art here. Dunno. Doesn't matter. If we have two techniques that will both work, a= nd one is patented, and the other is not, then we're just saving ourselves = future pain if we avoid the one that's patented. Patent litigation is a w= aste of time and money, and very much worth avoiding even if the patent bei= ng litigated has obvious prior art. (Of course, it's always possible that there's a submarine patent on includi= ng the MAC address in a DHCPv6 client packet... :) --_000_F3911B27B0C44AB180279D410247771Dnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4F51B315C663C34691834B9FEA2E5CB2@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 3:41 PM, Chuck Anderson <cra@WPI.EDU>
 wrote:
W= hich patent is it?  There may be documented prior art here.

Dunno.   Doesn't matter.   If we have two techniques that wi= ll both work, and one is patented, and the other is not, then we're just sa= ving ourselves future pain if we avoid the one that's patented.   Pate= nt litigation is a waste of time and money, and very much worth avoiding even if the patent being litigated has obvious pr= ior art.

(Of course, it's always possible that there's a submarine patent on in= cluding the MAC address in a DHCPv6 client packet... :)

--_000_F3911B27B0C44AB180279D410247771Dnominumcom_-- From sthaug@nethelp.no Thu Mar 15 12:47:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC41D21E8017 for ; Thu, 15 Mar 2012 12:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoXL7ytJjkrn for ; Thu, 15 Mar 2012 12:47:46 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id E656E21E800C for ; Thu, 15 Mar 2012 12:47:45 -0700 (PDT) Received: (qmail 63087 invoked from network); 15 Mar 2012 19:47:43 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Mar 2012 19:47:43 -0000 Date: Thu, 15 Mar 2012 20:47:43 +0100 (CET) Message-Id: <20120315.204743.41683190.sthaug@nethelp.no> To: Ted.Lemon@nominum.com From: sthaug@nethelp.no In-Reply-To: References: <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, wdec@cisco.com Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:47:47 -0000 > Most hosts implemented a changing DUID (DUID-LLT) on each client reset and the server allocated a new PD to each client! > > Such hosts do not have DHCPv6 clients: the spec expressly forbids this behavior. They have something that implements a DHCPv6-like configuration protocol, but it is not DHCPv6. > > The hardware address is an extremely poor choice for client identifier. Do we really need to have yet another interminable debate about this? As long as we can have the MAC address in some way, it doesn't have to be *the* client identifier. Having said that - I still haven't seen many positive comments about the various DUID forms from system / network administrators. I *have* seen lots of negative comments about not including the MAC address. In the IPv4 world my most frequent requirement is to *only* use the MAC address (and completely ignore the client identifier). I expect the same will be the case in the IPv6 world. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From Ted.Lemon@nominum.com Thu Mar 15 12:55:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F7121F8606 for ; Thu, 15 Mar 2012 12:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.423 X-Spam-Level: X-Spam-Status: No, score=-106.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps5c+i7UmP8m for ; Thu, 15 Mar 2012 12:55:22 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id A21E221F8604 for ; Thu, 15 Mar 2012 12:55:20 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT2JJKEhp7ZbCod1c5iQcw2B0Bz/ejGBV@postini.com; Thu, 15 Mar 2012 12:55:20 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C53CF1B82E4 for ; Thu, 15 Mar 2012 12:55:19 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BBDA019005C; Thu, 15 Mar 2012 12:55:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 12:55:19 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAARlICAACHKgIAABr6AgAACHAA= Date: Thu, 15 Mar 2012 19:55:19 +0000 Message-ID: <5990E6DD-4C4C-4ED5-935C-C78167746CDB@nominum.com> References: <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> <20120315.204743.41683190.sthaug@nethelp.no> In-Reply-To: <20120315.204743.41683190.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_5990E6DD4C4C4ED5935CC78167746CDBnominumcom_" MIME-Version: 1.0 Cc: "" , "" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:55:23 -0000 --_000_5990E6DD4C4C4ED5935CC78167746CDBnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 3:47 PM, > > wrote: Having said that - I still haven't seen many positive comments about the various DUID forms from system / network administrators. I *have* seen lots of negative comments about not including the MAC address. The DUID wasn't created with administrators in mind. It's an opaque, uniq= ue cookie used by the protocol. As well say that system administrators do= n't like the format of the shared keys in SSL. --_000_5990E6DD4C4C4ED5935CC78167746CDBnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 3:47 PM, <= sthaug@nethelp.no>
 <sthaug@nethelp.no&g= t; wrote:
H= aving said that - I still haven't seen many positive comments about
the various DUID forms from system / network administrators. I *have*seen lots of negative comments about not including the MAC address.

The DUID wasn't created with administrators in mind.   It's an op= aque, unique cookie used by the protocol.   As well say that system ad= ministrators don't like the format of the shared keys in SSL.

--_000_5990E6DD4C4C4ED5935CC78167746CDBnominumcom_-- From dankney@network1.net Thu Mar 15 12:59:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDBA21E8017 for ; Thu, 15 Mar 2012 12:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWAjTZZvSzSl for ; Thu, 15 Mar 2012 12:59:10 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id BAF1221E800C for ; Thu, 15 Mar 2012 12:59:10 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id EDE7754293F; Thu, 15 Mar 2012 15:59:09 -0400 (EDT) Date: Thu, 15 Mar 2012 15:59:09 -0400 (EDT) From: perl-list To: Ted Lemon Message-ID: <92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net> In-Reply-To: <5990E6DD-4C4C-4ED5-935C-C78167746CDB@nominum.com> Content-Type: multipart/alternative; boundary="=_7911e6d5-a077-46b4-9bf3-3811c14d60aa" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhcwg , wdec Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:59:11 -0000 --=_7911e6d5-a077-46b4-9bf3-3811c14d60aa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I hope this isn't going to descend into an argument about DUID vs hardware address. Client ID and chaddr managed to successfully co-exist in DHCPv4 ... perchance they can in DHCPv6 as well? ----- Original Message ----- > From: "Ted Lemon" > To: " " > Cc: "" , "" > > Sent: Thursday, March 15, 2012 3:55:19 PM > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > On Mar 15, 2012, at 3:47 PM, < sthaug@nethelp.no > > < sthaug@nethelp.no > wrote: > > Having said that - I still haven't seen many positive comments > > about > > > the various DUID forms from system / network administrators. I > > *have* > > > seen lots of negative comments about not including the MAC address. > > The DUID wasn't created with administrators in mind. It's an opaque, > unique cookie used by the protocol. As well say that system > administrators don't like the format of the shared keys in SSL. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=_7911e6d5-a077-46b4-9bf3-3811c14d60aa Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>I h= ope this isn't going to descend into an argument about DUID vs hardware add= ress. Client ID and chaddr managed to successfully co-exist in DHCPv4 ... p= erchance they can in DHCPv6 as well?


Fro= m: "Ted Lemon" <Ted.Lemon@nominum.com>
To: "<sthaug@= nethelp.no> <sthaug@nethelp.no>" <sthaug@nethelp.no>
C= c: "<dhcwg@ietf.org>" <dhcwg@ietf.org>, "<wdec@cisco.com= >" <wdec@cisco.com>
Sent: Thursday, March 15, 2012 3:55:= 19 PM
Subject: Re: [dhcwg] IETF83 dhcwg agenda items

On Mar 15, 2012, at 3:47 PM, <sthaug@nethelp.no>
Having said that - I still haven't seen many positive comments about
the various DUID forms from system / network administrators. I *have*seen lots of negative comments about not including the MAC address.

The DUID wasn't created with administrators in mind.   It's an op= aque, unique cookie used by the protocol.   As well say that system ad= ministrators don't like the format of the shared keys in SSL.


_______________________________________________
dhcwg mailing listdhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

--=_7911e6d5-a077-46b4-9bf3-3811c14d60aa-- From sthaug@nethelp.no Thu Mar 15 13:02:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF9421F861A for ; Thu, 15 Mar 2012 13:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H45rWRTkOg8A for ; Thu, 15 Mar 2012 13:02:11 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 7E8D621F8617 for ; Thu, 15 Mar 2012 13:02:10 -0700 (PDT) Received: (qmail 63614 invoked from network); 15 Mar 2012 20:02:09 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Mar 2012 20:02:09 -0000 Date: Thu, 15 Mar 2012 21:02:09 +0100 (CET) Message-Id: <20120315.210209.71144444.sthaug@nethelp.no> To: perl-list@network1.net From: sthaug@nethelp.no In-Reply-To: <92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net> References: <5990E6DD-4C4C-4ED5-935C-C78167746CDB@nominum.com> <92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, wdec@cisco.com, Ted.Lemon@nominum.com Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:02:11 -0000 > I hope this isn't going to descend into an argument about DUID vs hardware address. Client ID and chaddr managed to successfully co-exist in DHCPv4 ... perchance they can in DHCPv6 as well? As long as administrators can have the MAC address, I'm sure they can. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From dankney@network1.net Thu Mar 15 13:07:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37C21F8674 for ; Thu, 15 Mar 2012 13:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7itwRFfFz0No for ; Thu, 15 Mar 2012 13:06:59 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id B10A421F8628 for ; Thu, 15 Mar 2012 13:06:59 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 58E8054293F; Thu, 15 Mar 2012 16:06:59 -0400 (EDT) Date: Thu, 15 Mar 2012 16:06:59 -0400 (EDT) From: perl-list To: sthaug@nethelp.no Message-ID: <1a9b1c49-e3e3-413d-a335-4989b204bb89@zimbra.network1.net> In-Reply-To: <20120315.210209.71144444.sthaug@nethelp.no> Content-Type: multipart/alternative; boundary="=_eee8d88d-aa2b-4476-9198-2acad755c646" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhcwg@ietf.org, wdec@cisco.com, Ted Lemon Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:07:00 -0000 --=_eee8d88d-aa2b-4476-9198-2acad755c646 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I also support that statement. ----- Original Message ----- > From: sthaug@nethelp.no > To: perl-list@network1.net > Cc: "Ted Lemon" , dhcwg@ietf.org, > wdec@cisco.com > Sent: Thursday, March 15, 2012 4:02:09 PM > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > > I hope this isn't going to descend into an argument about DUID vs > > hardware address. Client ID and chaddr managed to successfully > > co-exist in DHCPv4 ... perchance they can in DHCPv6 as well? > As long as administrators can have the MAC address, I'm sure they > can. I also support that statement. --=_eee8d88d-aa2b-4476-9198-2acad755c646 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>I also support that statement.<= br>

From: sthaug@nethelp.no
To:= perl-list@network1.net
Cc: "Ted Lemon" <Ted.Lemon@nominum= .com>, dhcwg@ietf.org, wdec@cisco.com
Sent: Thursday, March 15= , 2012 4:02:09 PM
Subject: Re: [dhcwg] IETF83 dhcwg agenda items<= br>
> I hope this isn't going to descend into an argument about DUID = vs hardware address. Client ID and chaddr managed to successfully co-exist = in DHCPv4 ... perchance they can in DHCPv6 as well?

As long as admi= nistrators can have the MAC address, I'm sure they can.

I also suppo= rt that statement.


--=_eee8d88d-aa2b-4476-9198-2acad755c646-- From Ted.Lemon@nominum.com Thu Mar 15 13:09:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631F021E8017 for ; Thu, 15 Mar 2012 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQpVW4GYmRMf for ; Thu, 15 Mar 2012 13:09:59 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BD4CD21F86B9 for ; Thu, 15 Mar 2012 13:09:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT2JMkzpGoTKH9UI4JP4T/dzf6sefzGka@postini.com; Thu, 15 Mar 2012 13:09:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D54D11B831D for ; Thu, 15 Mar 2012 13:09:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CE87B19005C; Thu, 15 Mar 2012 13:09:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 13:09:54 -0700 From: Ted Lemon To: perl-list Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAARlICAACHKgIAABr6AgAACHACAAAEWgIAAAv+A Date: Thu, 15 Mar 2012 20:09:54 +0000 Message-ID: <4F11CE02-1ED6-4412-B51F-60F9EC932EBE@nominum.com> References: <92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net> In-Reply-To: <92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_4F11CE021ED64412B51F60F9EC932EBEnominumcom_" MIME-Version: 1.0 Cc: dhcwg , wdec Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:09:59 -0000 --_000_4F11CE021ED64412B51F60F9EC932EBEnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 3:59 PM, perl-list > wrote: I hope this isn't going to descend into an argument about DUID vs hardware = address. Client ID and chaddr managed to successfully co-exist in DHCPv4 ..= . perchance they can in DHCPv6 as well? Exactly right. --_000_4F11CE021ED64412B51F60F9EC932EBEnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 3:59 PM, perl-list <perl-list@network1.net> wrote:
I hope this isn't going to descend into an argument about DUID vs hardware a= ddress. Client ID and chaddr managed to successfully co-exist in DHCPv4 ...= perchance they can in DHCPv6 as well?

Exactly right.

--_000_4F11CE021ED64412B51F60F9EC932EBEnominumcom_-- From rdroms.ietf@gmail.com Thu Mar 15 15:55:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C075821F857D for ; Thu, 15 Mar 2012 15:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnLVi7deJ89E for ; Thu, 15 Mar 2012 15:55:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 303FC21F8585 for ; Thu, 15 Mar 2012 15:55:34 -0700 (PDT) Received: by qcsq13 with SMTP id q13so114012qcs.31 for ; Thu, 15 Mar 2012 15:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6Q4N1FImFIvCTetJu6w3FJExY4hYmHGPx8+7z/pbj2E=; b=qyJt03+dO1D9v0FkyonXZ084PswLKV01+ctPkuMSVAOidkYR3lPhaKkiqSfH3OxFJ7 c9bXaP55WfL4UD+4uF4Pj9oCXsFgDeI1rllq27PB7AbFsSqzxiri3AQCuFQae36mbmyd Z9bwGBWxoUGUPEq+1SkmWM+YEUCHiqB29hQx8NUGKfjZtjXq0quY9svRShZlQd8zHA1m eTmhgJ2eDFuoB1y+dEtvTvQUAFuoXHXcW3X5WZQk8Gus9L8wp/IgH1hIbImgNi9fPK6E a9kOzwRrMUTOlGOIC7PgKrChPEfVaEGt2GR5QvzcGIwHzRhqanlwnEl4tpSpOukJtyY4 kPNw== Received: by 10.229.69.30 with SMTP id x30mr167994qci.97.1331852133706; Thu, 15 Mar 2012 15:55:33 -0700 (PDT) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id w9sm6612823qao.0.2012.03.15.15.55.31 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 15:55:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <69D8496C-A4DB-4C6F-BB0D-17A20FCF8E0F@nominum.com> Date: Thu, 15 Mar 2012 18:55:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77df98dc-2430-439c-9f8f-f6e2abb13939@zimbra.network1.net> <69D8496C-A4DB-4C6F-BB0D-17A20FCF8E0F@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1251.1) Cc: dhc WG , "Wojciech Dec \(wdec\)" , Ralph Droms Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 22:55:34 -0000 On Mar 15, 2012, at 3:31 PM 3/15/12, Ted Lemon wrote: > On Mar 15, 2012, at 3:27 PM, perl-list wrote: >> Oh boy - yes a patented solution would not work very well unless it = can be guaranteed that one will ONLY run into Cisco gear in the field = (which it most assuredly cannot). >=20 > Cisco's offered the patent under FRAND terms, but you never know what = might happen going forward. Just to be clear, and recognizing my affiliation with Cisco, the IPR = disclosure includes the same licensing terms that have been found = acceptable in other situations (and, of course, have been found = unacceptable in some situations, as well). - Ralph From Ted.Lemon@nominum.com Thu Mar 15 17:51:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FD521E8056 for ; Thu, 15 Mar 2012 17:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.429 X-Spam-Level: X-Spam-Status: No, score=-106.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ucg7tmcdYifQ for ; Thu, 15 Mar 2012 17:51:22 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id B1BB621E800F for ; Thu, 15 Mar 2012 17:51:21 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT2KOiaVzU2nz4iiwbAT+RXvQgFO0PcQf@postini.com; Thu, 15 Mar 2012 17:51:21 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AE4821B8319 for ; Thu, 15 Mar 2012 17:51:20 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A216519005C; Thu, 15 Mar 2012 17:51:20 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 17:51:20 -0700 From: Ted Lemon To: Ralph Droms Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAAyhgCAAAH/gIAAAPSAgAA5GYCAACBdgA== Date: Fri, 16 Mar 2012 00:51:20 +0000 Message-ID: References: <77df98dc-2430-439c-9f8f-f6e2abb13939@zimbra.network1.net> <69D8496C-A4DB-4C6F-BB0D-17A20FCF8E0F@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_C011602FBFEA42748B05A85A6039685Enominumcom_" MIME-Version: 1.0 Cc: dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:51:22 -0000 --_000_C011602FBFEA42748B05A85A6039685Enominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 6:55 PM, Ralph Droms > wrote: Just to be clear, and recognizing my affiliation with Cisco, the IPR disclo= sure includes the same licensing terms that have been found acceptable in o= ther situations (and, of course, have been found unacceptable in some situa= tions, as well). Yup, nothing against Cisco. It's not a big deal, but it does make a diffe= rence. DHCP is fairly unencumbered by patents, with a few notable excepti= ons like Motorola's patent on the Relay Agent Information option. If we h= ave a choice I'd argue that we should choose the unencumbered solution, but= if the WG consensus turns out to be that the relay agent solution is bette= r, that's what we'll do. --_000_C011602FBFEA42748B05A85A6039685Enominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <383242F2D4457F4F872A824F0F59A193@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 6:55 PM, Ralph Droms <rdroms.ietf@gmail.com>
 wrote:
J= ust to be clear, and recognizing my affiliation with Cisco, the IPR disclosure= includes the same licensing terms that have been found acceptable in other= situations (and, of course, have been found unacceptable in some situation= s, as well).

Yup, nothing against Cisco.   It's not a big deal, but it does ma= ke a difference.   DHCP is fairly unencumbered by patents, with a few = notable exceptions like Motorola's patent on the Relay Agent Information op= tion.   If we have a choice I'd argue that we should choose the unencumbered solution, but if the WG consensus turns = out to be that the relay agent solution is better, that's what we'll do.

--_000_C011602FBFEA42748B05A85A6039685Enominumcom_-- From SRS0=1vDt=BX=WPI.EDU=cra@srs.wpi.edu Thu Mar 15 18:27:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF9C21E8056 for ; Thu, 15 Mar 2012 18:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7+fIrDfw+PO for ; Thu, 15 Mar 2012 18:27:40 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 53B5321E8049 for ; Thu, 15 Mar 2012 18:27:40 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q2G1RcOt009283; Thu, 15 Mar 2012 21:27:38 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q2G1RcOt009283 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1331861258; bh=J5tVjb8/naGVw44xiGwJwPn+7956iBrUO9Evm+SdF0o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=VPM3vbXrUqpOItqmyaWOLSkBoHwFM2Iu+PD3dhYY6OsGu8KQBEGsPfeX1EJjiozjW xjvezgT0OZrjjr2YKq1OxK1VcCs9j+k3PLdLzCVoMaVg/E/GiSGt8brwpN4bReeDSg ozuL0ZmpamKNZM+zTMVm0qnQ4hKDeFeY1L/Ft3LM= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q2G1RcIK009280; Thu, 15 Mar 2012 21:27:38 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q2G1RaeN017199; Thu, 15 Mar 2012 21:27:37 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id q2G1RZVa012871; Thu, 15 Mar 2012 21:27:35 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id q2G1RZKJ012869; Thu, 15 Mar 2012 21:27:35 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 15 Mar 2012 21:27:35 -0400 From: Chuck Anderson To: Ted Lemon Message-ID: <20120316012735.GW10760@angus.ind.WPI.EDU> Mail-Followup-To: Ted Lemon , Ralph Droms , dhc WG , "Wojciech Dec (wdec)" References: <77df98dc-2430-439c-9f8f-f6e2abb13939@zimbra.network1.net> <69D8496C-A4DB-4C6F-BB0D-17A20FCF8E0F@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dhc WG , "Wojciech Dec \(wdec\)" , Ralph Droms Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 01:29:05 -0000 On Fri, Mar 16, 2012 at 12:51:20AM +0000, Ted Lemon wrote: > On Mar 15, 2012, at 6:55 PM, Ralph Droms > > wrote: > Just to be clear, and recognizing my affiliation with Cisco, the IPR disclosure includes the same licensing terms that have been found acceptable in other situations (and, of course, have been found unacceptable in some situations, as well). > > Yup, nothing against Cisco. It's not a big deal, but it does make a difference. DHCP is fairly unencumbered by patents, with a few notable exceptions like Motorola's patent on the Relay Agent Information option. If we have a choice I'd argue that we should choose the unencumbered solution, but if the WG consensus turns out to be that the relay agent solution is better, that's what we'll do. I like the relay agent solution better, because it is easier for me to deploy a few relay agents with a new feature than to wait until my client base upgrades to a sufficient extent that I can write off old clients (e.g. not support/service them with DHCP, which might perhaps never happen). From shemant@cisco.com Thu Mar 15 18:32:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C026A21E8059 for ; Thu, 15 Mar 2012 18:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.061 X-Spam-Level: X-Spam-Status: No, score=-10.061 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMKZe98NF1Je for ; Thu, 15 Mar 2012 18:32:14 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0C21E8049 for ; Thu, 15 Mar 2012 18:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6800; q=dns/txt; s=iport; t=1331861534; x=1333071134; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=jZFK6tw+5tAj3Ec35D2Z9HF1APWaHI8qljU0hXfjZQM=; b=S2u+p0gKfQl1Sxk+q6RcTlvjfItqu1ctuOut62lf77WMKzTKL2VvPUc2 Zm+8GtDz+7TqXztNSOgi0E8HPAipzDjEfhXZAHHMyaQo3iRoFfXBv4D6X ePVs/yMchBJ1X6Vc7sxgYE5J+wb7IE88sGD/A20Cle4BwrGsRnkV0nSg5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAiXYk+tJXHB/2dsb2JhbABDgkWCd69zf4EHggkBAQEEEgEJBwoDSRACAQgRBAEBCwYXAQICAgEBRAkIAQEEARIIGodomnmNBJF/j3EzYwSIV5tJgWiDBA X-IronPort-AV: E=Sophos;i="4.73,594,1325462400"; d="scan'208,217";a="66915862" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 16 Mar 2012 01:31:52 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2G1Vqkm012798; Fri, 16 Mar 2012 01:31:52 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 20:31:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0314.909005B8" Date: Thu, 15 Mar 2012 20:31:51 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F7C@XMB-RCD-109.cisco.com> In-Reply-To: <92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: Ac0C5hlOA/vxLlIhRCSlciQfMtb4hAALcZbA References: <5990E6DD-4C4C-4ED5-935C-C78167746CDB@nominum.com> <92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net> From: "Hemant Singh (shemant)" To: "perl-list" , "Ted Lemon" X-OriginalArrivalTime: 16 Mar 2012 01:31:52.0680 (UTC) FILETIME=[90C6F680:01CD0314] Cc: dhcwg , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 01:32:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0314.909005B8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQpGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIHBlcmwtbGlzdA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE1 LCAyMDEyIDM6NTkgUE0NClRvOiBUZWQgTGVtb24NCkNjOiBkaGN3ZzsgV29qY2llY2ggRGVjICh3 ZGVjKQ0KU3ViamVjdDogUmU6IFtkaGN3Z10gSUVURjgzIGRoY3dnIGFnZW5kYSBpdGVtcw0KDQog DQoNCj5JIGhvcGUgdGhpcyBpc24ndCBnb2luZyB0byBkZXNjZW5kIGludG8gYW4gYXJndW1lbnQg YWJvdXQgRFVJRCB2cyBoYXJkd2FyZSBhZGRyZXNzLiBDbGllbnQgSUQgYW5kIGNoYWRkciBtYW5h Z2VkIHRvIHN1Y2Nlc3NmdWxseSBjby1leGlzdCBpbiBESENQdjQgLi4uIHBlcmNoYW5jZSB0aGV5 IGNhbiBpbiBESENQdjYgYXMgd2VsbD8NCg0KVGhhbmtzIGZvciB0aGlzIHJlbWluZGVyLiAgSW4g dGhhdCBjYXNlLCBjZXJ0YWlubHkgSSBhZ3JlZSB0b28gdGhhdCBjbGllbnQgaWQgYW5kIGNoYWRk ciBjYW4gY29leGlzdCBpbiBESENQdjYuICBJIGp1c3QgaGF2ZSBvbmUgbGFzdCBuaXQtcGljay4g IFNpeCBieXRlcyBvZiBtb3JlIGRhdGEgb24gdGhlIHdpcmUgYW5kIHRoYXQgbWFueSBtb3JlIGJ5 dGVzIHBlciBjbGllbnQgdG8gc3RvcmUgb24gdGhlIERIQ1B2NiBzZXJ2ZXIuIFNvcnJ5LCBteSBu YXR1cmFsIHRlbmRlbmN5IGlzIHRvIHVzZSBsZWFzdCBiaXRzIGV2ZXJ5d2hlcmUgc2luY2UgSSB3 b3JrIG9uIGVtYmVkZGVkIHN5c3RlbXMuDQoNCiANCg0KUmVnYXJkcywNCg0KIA0KDQpIZW1hbnQN Cg0K ------_=_NextPart_001_01CD0314.909005B8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQW5kYWxlIE1vbm8iOw0KCXBhbm9zZS0x OjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5wZXJsLWxpc3Q8YnI+ PGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxMiAzOjU5IFBNPGJyPjxiPlRvOjwv Yj4gVGVkIExlbW9uPGJyPjxiPkNjOjwvYj4gZGhjd2c7IFdvamNpZWNoIERlYyAod2RlYyk8YnI+ PGI+U3ViamVjdDo8L2I+IFJlOiBbZGhjd2ddIElFVEY4MyBkaGN3ZyBhZ2VuZGEgaXRlbXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFuZGFs ZSBNb25vIiwic2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFuZGFsZSBNb25vIiwic2VyaWYiO2NvbG9yOmJs YWNrJz5JIGhvcGUgdGhpcyBpc24ndCBnb2luZyB0byBkZXNjZW5kIGludG8gYW4gYXJndW1lbnQg YWJvdXQgRFVJRCB2cyBoYXJkd2FyZSBhZGRyZXNzLiBDbGllbnQgSUQgYW5kIGNoYWRkciBtYW5h Z2VkIHRvIHN1Y2Nlc3NmdWxseSBjby1leGlzdCBpbiBESENQdjQgLi4uIHBlcmNoYW5jZSB0aGV5 IGNhbiBpbiBESENQdjYgYXMgd2VsbD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5UaGFua3MgZm9yIHRoaXMgcmVtaW5kZXIuwqAgSW4g dGhhdCBjYXNlLCBjZXJ0YWlubHkgSSBhZ3JlZSB0b28gdGhhdCBjbGllbnQgaWQgYW5kIGNoYWRk ciBjYW4gY29leGlzdCBpbiBESENQdjYuwqAgSSBqdXN0IGhhdmUgb25lIGxhc3Qgbml0LXBpY2su wqAgU2l4IGJ5dGVzIG9mIG1vcmUgZGF0YSBvbiB0aGUgd2lyZSBhbmQgdGhhdCBtYW55IG1vcmUg Ynl0ZXMgcGVyIGNsaWVudCB0byBzdG9yZSBvbiB0aGUgREhDUHY2IHNlcnZlci4gU29ycnksIG15 IG5hdHVyYWwgdGVuZGVuY3kgaXMgdG8gdXNlIGxlYXN0IGJpdHMgZXZlcnl3aGVyZSBzaW5jZSBJ IHdvcmsgb24gZW1iZWRkZWQgc3lzdGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5IZW1hbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_001_01CD0314.909005B8-- From Ted.Lemon@nominum.com Thu Mar 15 18:56:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AD121E8036 for ; Thu, 15 Mar 2012 18:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPB9+zi0XYE0 for ; Thu, 15 Mar 2012 18:56:00 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 815BD21E8011 for ; Thu, 15 Mar 2012 18:56:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT2Kdr1tGf1Sj5lQBazCDpCNTp5g23/zI@postini.com; Thu, 15 Mar 2012 18:56:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4DB251B8315 for ; Thu, 15 Mar 2012 18:55:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 38DA0190052; Thu, 15 Mar 2012 18:55:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 18:55:59 -0700 From: Ted Lemon To: "Hemant Singh (shemant)" Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAARlICAACHKgIAABr6AgAACHACAAAEWgIAAXPSAgAAGvQA= Date: Fri, 16 Mar 2012 01:55:58 +0000 Message-ID: References: <5990E6DD-4C4C-4ED5-935C-C78167746CDB@nominum.com> <92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F7C@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F7C@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_C43837D4782A42408638423C59549CAEnominumcom_" MIME-Version: 1.0 Cc: dhcwg , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 01:56:01 -0000 --_000_C43837D4782A42408638423C59549CAEnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 9:31 PM, "Hemant Singh (shemant)" > wrote: Thanks for this reminder. In that case, certainly I agree too that client = id and chaddr can coexist in DHCPv6. I just have one last nit-pick. Six b= ytes of more data on the wire and that many more bytes per client to store = on the DHCPv6 server. Sorry, my natural tendency is to use least bits every= where since I work on embedded systems. This also argues for the relay agent solution, because then we can turn off= MAC addresses for the vast majority of cases where they are not needed. = E.g., my ISP does not need to know my MAC address, and on a typical home ga= teway, if any of them ever support DHCPv6, the MAC address will be superflu= ous. Like Chuck, I prefer this solution. I wish you guys hadn't patented it. --_000_C43837D4782A42408638423C59549CAEnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 9:31 PM, "Hemant Singh (shemant)" <shemant@cisco.com>
 wrote:
Thanks for this reminder.  In that case, certainly I agree too that client i= d and chaddr can coexist in DHCPv6.  I just have one last nit-pick.&nb= sp; Six bytes of more data on the wire and that many more bytes per client = to store on the DHCPv6 server. Sorry, my natural tendency is to use least bits everywhere since I work on embedded systems.=

This also argues for the relay agent solution, because then we can tur= n off MAC addresses for the vast majority of cases where they are not neede= d.   E.g., my ISP does not need to know my MAC address, and on a typic= al home gateway, if any of them ever support DHCPv6, the MAC address will be superfluous.

Like Chuck, I prefer this solution.   I wish you guys hadn't pate= nted it.

--_000_C43837D4782A42408638423C59549CAEnominumcom_-- From volz@cisco.com Thu Mar 15 19:52:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1821E803C for ; Thu, 15 Mar 2012 19:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.966 X-Spam-Level: X-Spam-Status: No, score=-9.966 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKOzjDnDrvQb for ; Thu, 15 Mar 2012 19:52:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E600121E8036 for ; Thu, 15 Mar 2012 19:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7028; q=dns/txt; s=iport; t=1331866354; x=1333075954; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=J6Xqounmuy/M/lzxWhx0bCyFp7sB1XxcyqFdvapZiOs=; b=Ykm7ztVgZVkh9HEMM4QaCI1fFgZa+Aesg+AK61QlakrtROElyALlz682 Idgn0i2sKR7Nq24tUxoR851ItF8A3tGO5Zsy3W1u1BnrmUxIDIGxiHEeH Wb7ZTBvnZFAdgZ2ZS6XDHwlladZ1NxrNSaqIYlyKzigYzjcLk5ZTFaDJk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADGqYk+tJV2d/2dsb2JhbABDgkWzaYEHggoBAQQSAQkRA0kQAgEIIgYYBgFWAgQbFwOHaJpynn6QFmMEiFabS4FogwQ X-IronPort-AV: E=Sophos;i="4.73,595,1325462400"; d="scan'208,217";a="63886567" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 16 Mar 2012 02:52:33 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2G2qXBD030201; Fri, 16 Mar 2012 02:52:33 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 21:52:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD031F.D59B74B4" Date: Thu, 15 Mar 2012 21:52:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAARlICAACHKgIAABr6AgAACHACAAAEWgIAAXPSAgAAGvQD//5Z4cA== References: <5990E6DD-4C4C-4ED5-935C-C78167746CDB@nominum.com><92d70be2-c4fa-4047-a1c3-9386b9071fe6@zimbra.network1.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F7C@XMB-RCD-109.cisco.com> From: "Bernie Volz (volz)" To: "Ted Lemon" X-OriginalArrivalTime: 16 Mar 2012 02:52:33.0101 (UTC) FILETIME=[D5E497D0:01CD031F] Cc: dhcwg Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 02:52:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD031F.D59B74B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted: =20 If there's a few minutes left on the agenda, I want to get a quick sense of if there is interest in the (now expired) Active DHCPv4 Lease Query draft (draft-kinnear-dhc-dhcpv6-active-leasequery-01). As hopefully the DHCPv4 Bulk Leasequery draft will move forward soon, be useful to see how much interest there is in active leasequery. We have implemented this (using something close to the draft) and have customers using it. So, there is some real demand. But the question is whether there is interest to standardize this by the DHC WG. Kim won't be at the IETF this time (hopefully next one), but I will be. While we need to take this to the list, asking at a WG meeting is a good indication. =20 - Bernie =20 ------_=_NextPart_001_01CD031F.D59B74B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted:

 

If there’s a few minutes left on the agenda, I want to get a = quick sense of if there is interest in the (now expired) Active DHCPv4 = Lease Query draft (draft-kinnear-dhc-dhcpv6-active-leasequery-01). As = hopefully the DHCPv4 Bulk Leasequery draft will move forward soon, be = useful to see how much interest there is in active leasequery. We have = implemented this (using something close to the draft) and have customers = using it. So, there is some real demand. But the question is whether = there is interest to standardize this by the DHC WG. Kim won’t be = at the IETF this time (hopefully next one), but I will be. While we need = to take this to the list, asking at a WG meeting is a good = indication.

 

-          = Bernie

 

------_=_NextPart_001_01CD031F.D59B74B4-- From dankney@network1.net Fri Mar 16 06:01:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055C621F86C6 for ; Fri, 16 Mar 2012 06:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFmS2EGBCMX7 for ; Fri, 16 Mar 2012 06:01:35 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id CB50621F86C1 for ; Fri, 16 Mar 2012 06:01:34 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 1920E542963; Fri, 16 Mar 2012 09:01:32 -0400 (EDT) Date: Fri, 16 Mar 2012 09:01:32 -0400 (EDT) From: perl-list To: Chuck Anderson Message-ID: <502f647c-9636-45b4-837e-94bde1c0a789@zimbra.network1.net> In-Reply-To: <20120316012735.GW10760@angus.ind.WPI.EDU> Content-Type: multipart/alternative; boundary="=_a02562c2-a683-44d0-9e08-3ad8e474dff6" MIME-Version: 1.0 X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhc WG , "Wojciech Dec \(wdec\)" , Ralph Droms , Ted Lemon Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 13:01:36 -0000 --=_a02562c2-a683-44d0-9e08-3ad8e474dff6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > I like the relay agent solution better, because it is easier for me > to > deploy a few relay agents with a new feature than to wait until my > client base upgrades to a sufficient extent that I can write off old > clients (e.g. not support/service them with DHCP, which might perhaps > never happen). > _______________________________________________ I also like the relay agent solution for that reason. Right now, however, we have a small handful of DHCPv6 clients available. Linux (ISC DHCP and Dibbler) ; D-Link ; MacOS ; Windows7+ ; Various commercial network equipment manufacturers such as Cisco and Juniper. Before the low end home router market enters the fray might be the time to change the client base... --=_a02562c2-a683-44d0-9e08-3ad8e474dff6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>
I like= the relay agent solution better, because it is easier for me to
deploy = a few relay agents with a new feature than to wait until my
client base = upgrades to a sufficient extent that I can write off old
clients (e.g. n= ot support/service them with DHCP, which might perhaps
never happen)._______________________________________________

I also= like the relay agent solution for that reason.  Right now, however, w= e have a small handful of DHCPv6 clients available.  Linux (ISC DHCP a= nd Dibbler) ; D-Link ; MacOS ; Windows7+ ; Various commercial network equip= ment manufacturers such as Cisco and Juniper.  Before the low end home= router market enters the fray might be the time to change the client base.= .. --=_a02562c2-a683-44d0-9e08-3ad8e474dff6-- From dankney@network1.net Fri Mar 16 06:58:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6ED621F8619 for ; Fri, 16 Mar 2012 06:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG+O4nPus9bf for ; Fri, 16 Mar 2012 06:58:36 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id BE35221F85ED for ; Fri, 16 Mar 2012 06:58:35 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 004B3542965; Fri, 16 Mar 2012 09:58:34 -0400 (EDT) Date: Fri, 16 Mar 2012 09:58:34 -0400 (EDT) From: perl-list To: Wojciech Dec Message-ID: <3a26d179-742d-4707-8730-a0965285349e@zimbra.network1.net> In-Reply-To: Content-Type: multipart/alternative; boundary="=_6186eb28-b417-4727-8360-ef710d02daad" MIME-Version: 1.0 X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhc WG , Ted Lemon , Ralph Droms Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 13:58:36 -0000 --=_6186eb28-b417-4727-8360-ef710d02daad Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Reading the IPR disclosure... I see what Cisco is doing here. Having a few = well placed patents to protect itself against patent trolls: " Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or= controls (either directly or indirectly) against Cisco" That actually makes good sense to me. Mutually assured destruction. ----- Original Message ----- > From: "Wojciech Dec" > To: "Ted Lemon" , "perl-list" > > Cc: "Hemant Singh (shemant)" , "dhc WG" > , "Ralph Droms" > Sent: Friday, March 16, 2012 4:38:01 AM > Subject: Re: [dhcwg] IETF83 dhcwg agenda items > Re: [dhcwg] IETF83 dhcwg agenda items The IPR disclosure re > draft-halwasia is under: > https://datatracker.ietf.org/ipr/1710/ > You=E2=80=99ll note that the license terms are free right to use under > reasonable, non-discriminatory terms, etc. > It=E2=80=99s perhaps also useful to note that IPR disclosures, and from > seemingly various sources apply to numerous DHCP drafts, including > RFC2131, and other standard RFCs. Where is the recommendation from > the chair(s) or the IETF not to use these RFCs or specific parts of > them, or not to consider drafts with disclosed IPR? > In terms of patent trolls, they=E2=80=99re likely not to be disclosing an= d we > can only speculate as to what obvious or not obvious IPRs they have > or don=E2=80=99t have, and the like. Or we can go back to being a technic= al > community, and leave such matters to subject matter experts, which > personally would be my preference. > -Woj. > On 15/03/2012 20:20, "Ted Lemon" < Ted.Lemon@nominum.com > wrote: > > On Mar 15, 2012, at 12:19 PM, perl-list < perl-list@network1.net > > > wrote: > > > > In case you are curious about the original 160+ message thread, > > > here > > > is a link to it: > > > > > > host-identifier with IPv6 > > > > > > https://lists.isc.org/pipermail/dhcp-users/2009-March/008489.html > > > > > It's probably worth noting that Cisco has, unfortunately, patented > > the original and ingenious technique whereby the relay agent > > captures the layer 2 source address from which it receives a client > > message, and records it in the relay agent options portion of the > > relayed message. > > > This argues, as you say, for having the client include the > > information, since I don't think Cisco has patented that. I > > personally prefer Cisco's ingenious and patented solution, but it's > > probably best not to use it, so as to avoid future patent trolling. > > > (In case any IP lawyers troll this message later, I'd like to be > > clear that I am being sarcastic when I call this technique > > ingenious. Were I speaking literally rather than sarcastically, I > > would describe it as blazingly obvious to any practitioner in the > > field.) > --=_6186eb28-b417-4727-8360-ef710d02daad Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>Rea= ding the IPR disclosure... I see what Cisco is doing here.  Having a f= ew well placed patents to protect itself against patent trolls:

"Cisco retains the right to asser= t its patents (including the right 
to claim past royalties= ) against any party that asserts a patent it owns or controls (either =
directly or indirectly) against Cisco"

= That actually makes good sense to me.  Mutually assured destruction.

From: "Wojciech Dec" <wdec@cisco= .com>
To: "Ted Lemon" <Ted.Lemon@nominum.com>, "perl-lis= t" <perl-list@network1.net>
Cc: "Hemant Singh (shemant)" &l= t;shemant@cisco.com>, "dhc WG" <dhcwg@ietf.org>, "Ralph Droms" <= ;rdroms@cisco.com>
Sent: Friday, March 16, 2012 4:38:01 AM
= Subject: Re: [dhcwg] IETF83 dhcwg agenda items

Re: [dhcwg] IETF83 dhcwg agenda items The IPR disclosure re draft-halwasia is under:
https:= //datatracker.ietf.org/ipr/1710/

You=E2=80=99ll note that the license terms are free right to use under reas= onable, non-discriminatory terms, etc.
It=E2=80=99s perhaps also useful to note that IPR disclosures, and from see= mingly various sources apply to numerous DHCP drafts, including RFC2131, an= d other standard RFCs.  Where is the recommendation from the chair(s) = or the IETF not to use these RFCs or specific parts of them, or not to cons= ider drafts with disclosed IPR?
In terms of patent trolls, they=E2=80=99re likely not to be disclosing and = we can only speculate as to what obvious or not obvious IPRs  they hav= e or don=E2=80=99t have, and the like. Or we can go back to being a technic= al community, and leave such matters to subject matter experts, which perso= nally would be my preference.

-Woj.


On 15/03/2012 20:20, "Ted Lemon" <Ted.Lemon@nominum.com> wrote= :

On Mar 15, 2012, at 12:19 PM, perl-list <= ;perl-list@network1.net> wrote:
In case you are curious about the original 160+ message thread, he= re is a link to it:

host-identifier with IPv6
https://lists.isc.org/pipermail/dhcp-users/200= 9-March/008489.html

It's probably worth noting that Cisco has, unfortunately, patented the orig= inal and ingenious technique whereby the relay agent captures the layer 2 s= ource address from which it receives a client message, and records it in th= e relay agent options portion of the relayed message.

This argues, as you say, for having the client include the information, sin= ce I don't think Cisco has patented that.  I personally prefer Cisco's= ingenious and patented solution, but it's probably best not to use it, so = as to avoid future patent trolling.

(In case any IP lawyers troll this message later, I'd like to be clear that= I am being sarcastic when I call this technique ingenious.   Wer= e I speaking literally rather than sarcastically, I would describe it as bl= azingly obvious to any practitioner in the field.)



--=_6186eb28-b417-4727-8360-ef710d02daad-- From Ted.Lemon@nominum.com Fri Mar 16 07:00:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2695F21F86A7 for ; Fri, 16 Mar 2012 07:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.434 X-Spam-Level: X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLPM+tgoltLi for ; Fri, 16 Mar 2012 07:00:35 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id BADD021F869A for ; Fri, 16 Mar 2012 07:00:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT2NHgiYg7h7EH8biqy1GTBDn0RTWAVCI@postini.com; Fri, 16 Mar 2012 07:00:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9EAD51B82F2 for ; Fri, 16 Mar 2012 07:00:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 93362190052; Fri, 16 Mar 2012 07:00:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 16 Mar 2012 07:00:33 -0700 From: Ted Lemon To: Wojciech Dec Thread-Topic: Client identifier IPR Thread-Index: AQHNA30nSKptGfbO40iekoV66sbLow== Date: Fri, 16 Mar 2012 14:00:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_EB0ECAB8876C4E20A22B1C04B2F28B77nominumcom_" MIME-Version: 1.0 Cc: dhc WG , Ralph Droms Subject: [dhcwg] Client identifier IPR X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:00:36 -0000 --_000_EB0ECAB8876C4E20A22B1C04B2F28B77nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 16, 2012, at 4:38 AM, Wojciech Dec > wrote: It=92s perhaps also useful to note that IPR disclosures, and from seemingly= various sources apply to numerous DHCP drafts, including RFC2131, and othe= r standard RFCs. Where is the recommendation from the chair(s) or the IETF= not to use these RFCs or specific parts of them, or not to consider drafts= with disclosed IPR? Any patent relating to RFC2131 would necessarily have expired by now. In terms of patent trolls, they=92re likely not to be disclosing and we can= only speculate as to what obvious or not obvious IPRs they have or don=92= t have, and the like. Or we can go back to being a technical community, and= leave such matters to subject matter experts, which personally would be my= preference. Cisco isn't a patent troll. But neither was Yahoo, ten years ago. I'm s= orry if it feels like I was suggesting otherwise; what I'm saying is simply= that given two solutions, both of which work, the one that's not patented = is preferable, regardless of licensing terms. There are actually some good technical reasons for choosing the relay-agent= -based solution, so it's not really an apples-to-apples comparison. My disappointment with Cisco in this case is simply that the patented techn= ique is dead obvious and is based on a technique documented (and also unfor= tunately patented!) by Motorola in RFC3046. So we have to make an unpleas= ant decision about this technique merely because someone at Cisco didn't sa= y "no" to the lawyers, and if we choose to go with the preferable technique= , we are putting future implementors at risk of litigation (the FRAND terms= protect present implementors, but it's not clear that they can't be withdr= awn, and certainly no assurance is given that they will not be withdrawn). Anyway, I suspect most of the people reading this are bored with this discu= ssion, and I apologize for continuing it, but you seemed surprised by my po= sition on the topic, so I just wanted to be clear about what I was saying. = I've changed the subject line so that people who don't want to hear any m= ore about this can mute it. --_000_EB0ECAB8876C4E20A22B1C04B2F28B77nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 16, 2012, at 4:38 AM, Wojciech Dec <wdec@cisco.com> wrote:
It=92s perhaps also useful to note that IPR disclosures, and from seemingly vario= us sources apply to numerous DHCP drafts, including RFC2131, and other stan= dard RFCs.  Where is the recommendation from the chair(s) or the IETF = not to use these RFCs or specific parts of them, or not to consider drafts with disclosed IPR? 

Any patent relating to RFC2131 would necessarily have expired by now.

In terms of patent trolls, they=92re likely not to be disclosing and we can o= nly speculate as to what obvious or not obvious IPRs  they have or don= =92t have, and the like. Or we can go back to being a technical community, = and leave such matters to subject matter experts, which personally would be my preference.

Cisco isn't a patent troll.   But neither was Yahoo, ten years ag= o.   I'm sorry if it feels like I was suggesting otherwise; what I'm s= aying is simply that given two solutions, both of which work, the one that'= s not patented is preferable, regardless of licensing terms.

There are actually some good technical reasons for choosing the relay-= agent-based solution, so it's not really an apples-to-apples comparison.

My disappointment with Cisco in this case is simply that the patented = technique is dead obvious and is based on a technique documented (and also = unfortunately patented!) by Motorola in RFC3046.   So we have to make = an unpleasant decision about this technique merely because someone at Cisco didn't say "no" to the lawyers, = and if we choose to go with the preferable technique, we are putting future= implementors at risk of litigation (the FRAND terms protect present implem= entors, but it's not clear that they can't be withdrawn, and certainly no assurance is given that they will not be wi= thdrawn).

Anyway, I suspect most of the people reading this are bored with this = discussion, and I apologize for continuing it, but you seemed surprised by = my position on the topic, so I just wanted to be clear about what I was say= ing.   I've changed the subject line so that people who don't want to hear any more about this can mute it= .

--_000_EB0ECAB8876C4E20A22B1C04B2F28B77nominumcom_-- From wdec@cisco.com Fri Mar 16 01:38:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ADD21F85C0 for ; Fri, 16 Mar 2012 01:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.705 X-Spam-Level: X-Spam-Status: No, score=-109.705 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXI+pZouKmTs for ; Fri, 16 Mar 2012 01:38:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 923E421F8713 for ; Fri, 16 Mar 2012 01:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=5725; q=dns/txt; s=iport; t=1331887088; x=1333096688; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=cIP8krKU/st4OLF1AiTc7VPr+i1FiZszxKLE4pOhQzY=; b=axP1/Y+MKGTc5BkEgAOIUYe+tCmt7wJmFeLlXcz1rFbWTBi4cDR7VV0O PDJMQ39uplJeQ7r6XO3kySDULlCnp4v7AyjtvRyhdGPI0Zv4AaLgnyNTe jHZLwaMDsDApgMrwIjSK/9gD0/PwzjlKsCZ55Dab/3EbsMWcbGSs+2AXR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJD6Yk+Q/khL/2dsb2JhbABDgkWydXeBB4IJAQEBAwEBAg8BKi4OBQ0BCAQUVi8CBAENBRQHB4djBQuaYJ8ABJB5BIgjixSCK44/gWiCZw X-IronPort-AV: E=Sophos;i="4.73,597,1325462400"; d="scan'208,217";a="132498534" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2012 08:38:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2G8c7r0013426; Fri, 16 Mar 2012 08:38:07 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 09:38:07 +0100 Received: from 10.61.81.85 ([10.61.81.85]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Mar 2012 08:38:06 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 16 Mar 2012 09:38:01 +0100 From: Wojciech Dec To: Ted Lemon , perl-list Message-ID: Thread-Topic: [dhcwg] IETF83 dhcwg agenda items Thread-Index: AQHNAIDENpBD1bgWjE6aBleM+G6EJ5Znnlx4gAPEQ7CAAJ4pAIAAAmwAgAAyhgCAAGl1bw== In-Reply-To: <8767518B-0EB7-4C9C-9B22-70E7B706EDFC@nominum.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414735485_54711615" X-OriginalArrivalTime: 16 Mar 2012 08:38:07.0379 (UTC) FILETIME=[1C7C5630:01CD0350] X-Mailman-Approved-At: Fri, 16 Mar 2012 07:01:00 -0700 Cc: dhc WG , Ralph Droms Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 08:38:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414735485_54711615 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The IPR disclosure re draft-halwasia is under: https://datatracker.ietf.org/ipr/1710/ You=B9ll note that the license terms are free right to use under reasonable, non-discriminatory terms, etc. It=B9s perhaps also useful to note that IPR disclosures, and from seemingly various sources apply to numerous DHCP drafts, including RFC2131, and other standard RFCs. Where is the recommendation from the chair(s) or the IETF not to use these RFCs or specific parts of them, or not to consider drafts with disclosed IPR? In terms of patent trolls, they=B9re likely not to be disclosing and we can only speculate as to what obvious or not obvious IPRs they have or don=B9t have, and the like. Or we can go back to being a technical community, and leave such matters to subject matter experts, which personally would be my preference. -Woj. On 15/03/2012 20:20, "Ted Lemon" wrote: > On Mar 15, 2012, at 12:19 PM, perl-list wrote: >> In case you are curious about the original 160+ message thread, here is = a >> link to it:=20 >>=20 >> host-identifier with IPv6 >> https://lists.isc.org/pipermail/dhcp-users/2009-March/008489.html >=20 > It's probably worth noting that Cisco has, unfortunately, patented the > original and ingenious technique whereby the relay agent captures the lay= er 2 > source address from which it receives a client message, and records it in= the > relay agent options portion of the relayed message. >=20 > This argues, as you say, for having the client include the information, s= ince > I don't think Cisco has patented that. I personally prefer Cisco's ingen= ious > and patented solution, but it's probably best not to use it, so as to avo= id > future patent trolling. >=20 > (In case any IP lawyers troll this message later, I'd like to be clear th= at I > am being sarcastic when I call this technique ingenious. Were I speakin= g > literally rather than sarcastically, I would describe it as blazingly obv= ious > to any practitioner in the field.) >=20 >=20 --B_3414735485_54711615 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dhcwg] IETF83 dhcwg agenda items The IPR disclosure re draft-halwasia is under:
https://datatracker.ietf.o= rg/ipr/1710/

You’ll note that the license terms are free right to use under reason= able, non-discriminatory terms, etc.
It’s perhaps also useful to note that IPR disclosures, and from seemi= ngly various sources apply to numerous DHCP drafts, including RFC2131, and o= ther standard RFCs.  Where is the recommendation from the chair(s) or t= he IETF not to use these RFCs or specific parts of them, or not to consider = drafts with disclosed IPR?
In terms of patent trolls, they’re likely not to be disclosing and we= can only speculate as to what obvious or not obvious IPRs  they have o= r don’t have, and the like. Or we can go back to being a technical com= munity, and leave such matters to subject matter experts, which personally w= ould be my preference.

-Woj.


On 15/03/2012 20:20, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>On Mar 15, 2012, at 12:19 PM, perl-list <perl-list@network1.net> wrote:
In case you are curious about the original 160+ message thread, here is= a link to it:

= host-identifier with IPv6
https://lists.isc.org/pipermail/dhcp-users/2009-March/008489.html

It's probably worth noting that Cisco has, unfortunately, patented the orig= inal and ingenious technique whereby the relay agent captures the layer 2 so= urce address from which it receives a client message, and records it in the = relay agent options portion of the relayed message.

This argues, as you say, for having the client include the information, sin= ce I don't think Cisco has patented that.  I personally prefer Cisco's = ingenious and patented solution, but it's probably best not to use it, so as= to avoid future patent trolling.

(In case any IP lawyers troll this message later, I'd like to be clear that= I am being sarcastic when I call this technique ingenious.   Were= I speaking literally rather than sarcastically, I would describe it as blaz= ingly obvious to any practitioner in the field.)


--B_3414735485_54711615-- From linux@thehobsons.co.uk Fri Mar 16 07:39:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3670D21F86CB for ; Fri, 16 Mar 2012 07:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heQIJQgivHfF for ; Fri, 16 Mar 2012 07:39:30 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id E771D21F8650 for ; Fri, 16 Mar 2012 07:39:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id BB19D29FC3 for ; Fri, 16 Mar 2012 14:39:26 +0000 (GMT) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zItMtRHrSedp for ; Fri, 16 Mar 2012 14:39:26 +0000 (GMT) Received: from simon.thehobsons.co.uk (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 3557829ED6 for ; Fri, 16 Mar 2012 14:39:25 +0000 (GMT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> Date: Fri, 16 Mar 2012 14:39:11 +0000 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:39:31 -0000 Ted Lemon wrote: >The hardware address is an extremely poor choice for client >identifier. Do we really need to have yet another interminable >debate about this? Probably not. I thought a consensus was reached in "that thread" that : a) the hardware address of the client isn't a good choice, but b) we don't have anything better, c) the hardware address is very often printed on the outside of the box and so can be determined without powering up the equipment, d) most of the DUID options defined do not give an identifier that can be determined prior to the device being powered up and allowed to generate it e) in many environments, changing/re-installing OS is at least as common (if not more so) as changing hardware. And multi-OS boot options also introduce changes in DUID and f) many people have workflow requirements which require a known and defined identifier. On that basis, the hardware address is the least bad choice that generally meets most admins' requirements (some permutation of c-f) - while in the general case, only one (the least likely to be found) of the DUID options do not. Also, I think we reached a consensus that in the general case, there is no way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by matching port IDs from relay agents), but in the general case IPv6 clients will be using DUIDs which we are specifically barred from looking into even if they did contain the same hardware address as is currently used for the interface. If there was some standard that said all network devices had to have a globally unique identifier, stored immutably in hardware, and determinable in advance (eg scanning a barcode on the box) then we'd not be having these discussions. But that's not going to happen, so we are stuck with making the best of what we do have. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From akostur@incognito.com Fri Mar 16 07:51:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1681921F8671 for ; Fri, 16 Mar 2012 07:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.921 X-Spam-Level: X-Spam-Status: No, score=-4.921 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1umhTvwgF8aa for ; Fri, 16 Mar 2012 07:51:21 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with SMTP id ECE0221F8623 for ; Fri, 16 Mar 2012 07:51:19 -0700 (PDT) Received: from mail-lpp01m010-f47.google.com ([209.85.215.47]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKT2NTZkyy9qmpba4c4ifRr+34kyh+n+42@postini.com; Fri, 16 Mar 2012 07:51:20 PDT Received: by mail-lpp01m010-f47.google.com with SMTP id w12so3689385lag.20 for ; Fri, 16 Mar 2012 07:51:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8NzGYTiVgr6LLn3tsQVYgfGxhMtPgVZK+dg7qgeuTis=; b=WBDeap7Wc8bLAGo9YHg4T7hU+W5M4OccBa8JNmPtHtu2ia4wH1Z2h/vh/riDBygixD M4LK5FGHgKgZf6skqpWQVWRi7E1ZDY2ekBFUioRTSuDdfP0t9HH8q+wThMQGzCSR+lLS 7W3TNylk155isIMBosAO6cSxSL9uD0CdnzvcEEJORj9IyGzCw0wseURa6NFuiR//6acH 5R7HKxoAHSfI38re+7Z1q7fUeis+hR7Nr2U4IRp4mmSqe/mWXHjBts4E8Dk1GMqbW7Fb C6iOOOoUKNVyHB7gRlLEG6lSrAxrZ324Z4HJa+SHuqnsYL6x5mKakuzxM5XENNBc+DNN +GqA== MIME-Version: 1.0 Received: by 10.112.42.7 with SMTP id j7mr1007957lbl.75.1331909478207; Fri, 16 Mar 2012 07:51:18 -0700 (PDT) Received: by 10.112.86.135 with HTTP; Fri, 16 Mar 2012 07:51:18 -0700 (PDT) In-Reply-To: References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> Date: Fri, 16 Mar 2012 07:51:18 -0700 Message-ID: From: Andre Kostur To: Simon Hobson Content-Type: multipart/alternative; boundary=e0cb4efa6e3652524604bb5d577a X-Gm-Message-State: ALoCoQmAtkOUIG5KjY9+SJHpmxAG6cRRdqHe6A5u4BJyCJfFXb/t8FPPMjZu+kLlpjXvQQueftLx Cc: dhcwg@ietf.org Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:51:22 -0000 --e0cb4efa6e3652524604bb5d577a Content-Type: text/plain; charset=ISO-8859-1 The prohibition of looking into the DUID may be one of the issues. A DUID-LLT doesn't give you any reliable info, and a DUID-EN gives you almost nothing (although I suppose vendors could print the EN part on the box, making it a useful identifier for the aforementioned workflow). However, the DUID-LL is defined as having a current network link address. One could use that in place of a MAC address in certain known areas (cable modems, for example. Use the HFC MAC address to compose the DUID-LL). We've got RFC 6355 (DUID-UUID) and RFC 4361 (DUID in DHCPv4 client identifiers), when taken together would be able to do most of the things that are mentioned. On Fri, Mar 16, 2012 at 07:39, Simon Hobson wrote: > Ted Lemon wrote: > > The hardware address is an extremely poor choice for client identifier. >> Do we really need to have yet another interminable debate about this? >> > > Probably not. I thought a consensus was reached in "that thread" that : > > a) the hardware address of the client isn't a good choice, > > but b) we don't have anything better, > > c) the hardware address is very often printed on the outside of the box > and so can be determined without powering up the equipment, > > d) most of the DUID options defined do not give an identifier that can be > determined prior to the device being powered up and allowed to generate it > > e) in many environments, changing/re-installing OS is at least as common > (if not more so) as changing hardware. And multi-OS boot options also > introduce changes in DUID > > and f) many people have workflow requirements which require a known and > defined identifier. > > On that basis, the hardware address is the least bad choice that generally > meets most admins' requirements (some permutation of c-f) - while in the > general case, only one (the least likely to be found) of the DUID options > do not. > > > Also, I think we reached a consensus that in the general case, there is no > way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by > matching port IDs from relay agents), but in the general case IPv6 clients > will be using DUIDs which we are specifically barred from looking into even > if they did contain the same hardware address as is currently used for the > interface. > > > If there was some standard that said all network devices had to have a > globally unique identifier, stored immutably in hardware, and determinable > in advance (eg scanning a barcode on the box) then we'd not be having these > discussions. But that's not going to happen, so we are stuck with making > the best of what we do have. > > -- > Simon Hobson > > Visit http://www.**magpiesnestpublishing.co.uk/for books by acclaimed > author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas stocking fillers. Some available as e-books. > > ______________________________**_________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/**listinfo/dhcwg > -- *Andre Kostur* * * --e0cb4efa6e3652524604bb5d577a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The prohibition of looking into the DUID may be one of the= issues. =A0A DUID-LLT doesn't give you any reliable info, and a DUID-E= N gives you almost nothing (although I suppose vendors could print the EN p= art on the box, making it a useful identifier for the aforementioned workfl= ow). =A0However, the DUID-LL is defined as having a current network link ad= dress. =A0One could use that in place of a MAC address in certain known are= as (cable modems, for example. =A0Use the HFC MAC address to compose the DU= ID-LL).

We've got RFC 6355 (DUID-UUID) and RFC 4361 (DUID in DHC= Pv4 client identifiers), when taken together would be able to do most of th= e things that are mentioned.


On Fri, Mar 16, 2012 at 07:39, Simon Hobson <linux@thehobsons.co.uk> wr= ote:
Ted Lemon wrote:

The hardware address is an extremely poor choice for client identifier. =A0= Do we really need to have yet another interminable debate about this?

Probably not. I thought a consensus was reached in "that thread" = that :

a) the hardware address of the client isn't a good choice,

but b) we don't have anything better,

c) the hardware address is very often printed on the outside of the box and= so can be determined without powering up the equipment,

d) most of the DUID options defined do not give an identifier that can be d= etermined prior to the device being powered up and allowed to generate it
e) in many environments, changing/re-installing OS is at least as common (i= f not more so) as changing hardware. And multi-OS boot options also introdu= ce changes in DUID

and f) many people have workflow requirements which require a known and def= ined identifier.

On that basis, the hardware address is the least bad choice that generally = meets most admins' requirements (some permutation of c-f) - while in th= e general case, only one (the least likely to be found) of the DUID options= do not.


Also, I think we reached a consensus that in the general case, there is no = way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by= matching port IDs from relay agents), but in the general case IPv6 clients= will be using DUIDs which we are specifically barred from looking into eve= n if they did contain the same hardware address as is currently used for th= e interface.


If there was some standard that said all network devices had to have a glob= ally unique identifier, stored immutably in hardware, and determinable in a= dvance (eg scanning a barcode on the box) then we'd not be having these= discussions. But that's not going to happen, so we are stuck with maki= ng the best of what we do have.

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed<= br> author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg



--
=
Andre= Kostur



--e0cb4efa6e3652524604bb5d577a-- From linux@thehobsons.co.uk Fri Mar 16 07:55:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EFF21F8735 for ; Fri, 16 Mar 2012 07:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm4LS2emzrWs for ; Fri, 16 Mar 2012 07:55:35 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 6340E21F8745 for ; Fri, 16 Mar 2012 07:55:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 2672A29FC3 for ; Fri, 16 Mar 2012 14:55:34 +0000 (GMT) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5k45PobHKul for ; Fri, 16 Mar 2012 14:55:34 +0000 (GMT) Received: from simon.thehobsons.co.uk (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 9B52929ED6 for ; Fri, 16 Mar 2012 14:55:33 +0000 (GMT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> Date: Fri, 16 Mar 2012 14:55:29 +0000 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:55:36 -0000 I wrote: >On that basis, the hardware address is the least bad choice that >generally meets most admins' requirements (some permutation of c-f) >- while in the general case, only one (the least likely to be found) >of the DUID options do not. Oops, typo there. It should say : >while in the general case, only one (the least likely to be found) >of the DUID options does -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From Ted.Lemon@nominum.com Fri Mar 16 08:43:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987C221F86EE for ; Fri, 16 Mar 2012 08:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9jYWctXJZPS for ; Fri, 16 Mar 2012 08:43:16 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D3F8521F863D for ; Fri, 16 Mar 2012 08:43:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT2Nfkln9c1e2nyCEwp1ERPQQZkgKkNEx@postini.com; Fri, 16 Mar 2012 08:43:15 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 896911B830D for ; Fri, 16 Mar 2012 08:43:14 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7E693190052; Fri, 16 Mar 2012 08:43:14 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 16 Mar 2012 08:43:14 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] DUID vs MAC address: the fight of the century! Thread-Index: AQHNA4t/ehSCa6OJu0aHIrVoEwCDtw== Date: Fri, 16 Mar 2012 15:43:13 +0000 Message-ID: <2B88B3F1-9A2F-438A-A833-F4F5A5D9ED1E@nominum.com> References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_2B88B3F19A2F438AA833F4F5A5D9ED1Enominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:43:17 -0000 --_000_2B88B3F19A2F438AA833F4F5A5D9ED1Enominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mar 16, 2012, at 10:51 AM, Andre Kostur > wrote: The prohibition of looking into the DUID may be one of the issues. A DUID-= LLT doesn't give you any reliable info, and a DUID-EN gives you almost noth= ing (although I suppose vendors could print the EN part on the box, making = it a useful identifier for the aforementioned workflow). However, the DUID= -LL is defined as having a current network link address. One could use tha= t in place of a MAC address in certain known areas (cable modems, for examp= le. Use the HFC MAC address to compose the DUID-LL). That prohibition was against treating the parts of the DUID separately for = the purpose of identifying the client. It was never intended that you cou= ldn't look at it, just that you couldn't extract the MAC address and use it= as a client identifier by itself. --_000_2B88B3F19A2F438AA833F4F5A5D9ED1Enominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 16, 2012, at 10:51 AM, Andre Kostur <akostur@incognito.com> wrote:
T= he prohibition of looking into the DUID may be one of the issues.  A DUI= D-LLT doesn't give you any reliable info, and a DUID-EN gives you almost no= thing (although I suppose vendors could print the EN part on the box, makin= g it a useful identifier for the aforementioned workflow).  However, the DUID-LL is defined as having a current netwo= rk link address.  One could use that in place of a MAC address in cert= ain known areas (cable modems, for example.  Use the HFC MAC address t= o compose the DUID-LL).

That prohibition was against treating the parts of the DUID separately= for the purpose of identifying the client.   It was never intended th= at you couldn't look at it, just that you couldn't extract the MAC address = and use it as a client identifier by itself.

--_000_2B88B3F19A2F438AA833F4F5A5D9ED1Enominumcom_-- From Ted.Lemon@nominum.com Fri Mar 16 08:47:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6DE21F866C for ; Fri, 16 Mar 2012 08:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.44 X-Spam-Level: X-Spam-Status: No, score=-106.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tstngypqBWcq for ; Fri, 16 Mar 2012 08:47:19 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id A7A8C21F866D for ; Fri, 16 Mar 2012 08:47:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT2NghqajbFSJl9R+fTFBiMl0l83iex5F@postini.com; Fri, 16 Mar 2012 08:47:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E30651B8310 for ; Fri, 16 Mar 2012 08:47:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DB25C190052; Fri, 16 Mar 2012 08:47:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 16 Mar 2012 08:47:17 -0700 From: Ted Lemon To: Simon Hobson Thread-Topic: [dhcwg] DUID vs MAC address: the fight of the century! Thread-Index: AQHNA4wQylI0h3lqoU64F2JcJ4g3aQ== Date: Fri, 16 Mar 2012 15:47:17 +0000 Message-ID: References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_DDCA109E1CDF49E49F3C6B86CE14E91Enominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:47:19 -0000 --_000_DDCA109E1CDF49E49F3C6B86CE14E91Enominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 16, 2012, at 10:39 AM, Simon Hobson > wrote: Also, I think we reached a consensus that in the general case, there is no = way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by= matching port IDs from relay agents), but in the general case IPv6 clients= will be using DUIDs which we are specifically barred from looking into eve= n if they did contain the same hardware address as is currently used for th= e interface. This was not a working group discussion; what consensus may have been reach= ed on the ISC DHCP mailing list is not a matter of interest to the working = group. If you want to participate in the working group, that's great, but= please don't present this as a fait accomplis. The fact is that there are definitely use cases where the MAC address is a = useful key to be used for associating the device in the box with a back off= ice database record. However, it's also almost certainly true that in _ev= ery single case_ like this, DUID-LL is a valid identifier to use. So if we really want to go down the road you're proposing, Simon, I think t= hat the right thing to do is to _require_ that DUID-LL be used instead of D= UID-LLT in those cases where it is applicable, and to permit DHCP servers t= o examine the link layer address contained within the DUID-LL for the purpo= ses of matching records in back office databases that may have been generat= ed by reading bar codes off the side of boxes. --_000_DDCA109E1CDF49E49F3C6B86CE14E91Enominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9D07F27345A1F44F966507A812D2544F@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 16, 2012, at 10:39 AM, Simon Hobson <linux@thehobsons.co.uk> wrote:
A= lso, I think we reached a consensus that in the general case, there is no way t= o match IPv4 clients with IPv6 clients. It may be in some cases (eg by matc= hing port IDs from relay agents), but in the general case IPv6 clients will= be using DUIDs which we are specifically barred from looking into even if they did contain the same hardware addres= s as is currently used for the interface.

This was not a working group discussion; what consensus may have been = reached on the ISC DHCP mailing list is not a matter of interest to the wor= king group.   If you want to participate in the working group, that's = great, but please don't present this as a fait accomplis.

The fact is that there are definitely use cases where the MAC address = is a useful key to be used for associating the device in the box with a bac= k office database record.   However, it's also almost certainly true t= hat in _every single case_ like this, DUID-LL is a valid identifier to use.

So if we really want to go down the road you're proposing, Simon, I th= ink that the right thing to do is to _require_ that DUID-LL be used instead= of DUID-LLT in those cases where it is applicable, and to permit DHCP serv= ers to examine the link layer address contained within the DUID-LL for the purposes of matching records in back = office databases that may have been generated by reading bar codes off the = side of boxes.

--_000_DDCA109E1CDF49E49F3C6B86CE14E91Enominumcom_-- From dankney@network1.net Fri Mar 16 09:34:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852C921F85DB for ; Fri, 16 Mar 2012 09:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0ymF-P9yiz7 for ; Fri, 16 Mar 2012 09:34:00 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id C48DE21F85D8 for ; Fri, 16 Mar 2012 09:34:00 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 5566754296B; Fri, 16 Mar 2012 12:33:58 -0400 (EDT) Date: Fri, 16 Mar 2012 12:33:58 -0400 (EDT) From: perl-list To: Ted Lemon Message-ID: In-Reply-To: Content-Type: multipart/alternative; boundary="=_987e6d06-2249-495b-8381-aa1dcb3a8832" MIME-Version: 1.0 X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhcwg Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 16:34:01 -0000 --=_987e6d06-2249-495b-8381-aa1dcb3a8832 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > The fact is that there are definitely use cases where the MAC address > is a useful key to be used for associating the device in the box > with a back office database record. However, it's also almost > certainly true that in _every single case_ like this, DUID-LL is a > valid identifier to use. DUID-LL - true - the hardware address is in that one .... it cannot be guaranteed that method will be used by the client since there are two others. --=_987e6d06-2249-495b-8381-aa1dcb3a8832 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

The fact is that there are definitely use cases where the MAC address is a useful key to be used for associating the device in the box with a back office database record.   However, it's also almost certainly true that in _every single case_ like this, DUID-LL is a valid identifier to use.



DUID-LL - true - the hardware address is in that one ....  it cannot be guaranteed that method will be used by the client since there are two others.
--=_987e6d06-2249-495b-8381-aa1dcb3a8832-- From linux@thehobsons.co.uk Fri Mar 16 10:12:20 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B754921E8012 for ; Fri, 16 Mar 2012 10:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJZcuTQU69wg for ; Fri, 16 Mar 2012 10:12:19 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id AC04821F86EE for ; Fri, 16 Mar 2012 10:12:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id F24E910401A for ; Fri, 16 Mar 2012 17:12:16 +0000 (GMT) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZdxE6iJNr4l for ; Fri, 16 Mar 2012 17:12:16 +0000 (GMT) Received: from simon.thehobsons.co.uk (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 2A89329ED6 for ; Fri, 16 Mar 2012 17:12:13 +0000 (GMT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2B88B3F1-9A2F-438A-A833-F4F5A5D9ED1E@nominum.com> References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> <2B88B3F1-9A2F-438A-A833-F4F5A5D9ED1E@nominum.com> Date: Fri, 16 Mar 2012 17:12:08 +0000 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:12:20 -0000 Ted Lemon wrote: >>The prohibition of looking into the DUID may be one of the issues. >> A DUID-LLT doesn't give you any reliable info, and a DUID-EN gives >>you almost nothing (although I suppose vendors could print the EN >>part on the box, making it a useful identifier for the >>aforementioned workflow). However, the DUID-LL is defined as >>having a current network link address. One could use that in place >>of a MAC address in certain known areas (cable modems, for example. >> Use the HFC MAC address to compose the DUID-LL). >> > >That prohibition was against treating the parts of the DUID >separately for the purpose of identifying the client. It was never >intended that you couldn't look at it, just that you couldn't >extract the MAC address and use it as a client identifier by itself. That, I have to say is semantic wriggling. Since the discussion is about the utility of the hardware address for various requirements, saying it's in there but you can't extract it and look at it is merely an admission that as defined, it is not useful for the sort of things people in the real world are wanting to do. Ted Lemon wrote: >On Mar 16, 2012, at 10:39 AM, Simon Hobson ><linux@thehobsons.co.uk> wrote: > >>Also, I think we reached a consensus that in the general case, >>there is no way to match IPv4 clients with IPv6 clients. It may be >>in some cases (eg by matching port IDs from relay agents), but in >>the general case IPv6 clients will be using DUIDs which we are >>specifically barred from looking into even if they did contain the >>same hardware address as is currently used for the interface. >This was not a working group discussion; what consensus may have >been reached on the ISC DHCP mailing list is not a matter of >interest to the working group. If you want to participate in the >working group, that's great, but please don't present this as a fait >accomplis. I did not say it was, did not say otherwise, and did not present it as such. What I stated was factually accurate (as far as I recall). The only thing I may have left out is "(on the DHCP Users mailing list) we reached a consensus (on what users want/need) ..." If the DHC working group really has no interest in what users think then I think that says a lot. Some people who are on the WG were well aware of users feelings, now if that never entered any discussion I think those people involved perhaps need to consider the function and purpose of standards. Your comment is perhaps valid, but would the current structure still work if suddenly a *lot* of users joined the WG to air their views - rather than trusting that those who are already on the WG and are fully aware of those view might perhaps air them ? Perhaps I'm reading too much into this, and I really don't want to flog what's left of this old equine carcass any more, but your attitude does suggest an element of "if you don't air it at the WG we don't give a about what users think or need." I hope that's not the case, but it is how it comes across. >The fact is that there are definitely use cases where the MAC >address is a useful key to be used for associating the device in the >box with a back office database record. However, it's also almost >certainly true that in _every single case_ like this, DUID-LL is a >valid identifier to use. That may be almost true, but what is equally true is that it is the least likely DUID option to be present. My understanding (from memory, correct me if I'm wrong) is that on any device with persistent storage, use of DUID-LL is deprecated in favour of one of the other options. Unless DUID-LL is present from **ALL** devices, then it cannot be used to substitute for hardware address (or some better identifier). >So if we really want to go down the road you're proposing, Simon, I >think that the right thing to do is to _require_ that DUID-LL be >used instead of DUID-LLT in those cases where it is applicable, and >to permit DHCP servers to examine the link layer address contained >within the DUID-LL for the purposes of matching records in back >office databases that may have been generated by reading bar codes >off the side of boxes. That would probably suit *most* use cases people are talking about. To suit *all* use cases, you'd also have to mandate that all DHCPv4 clients also send that option. The chances of getting that passed **and** into common usage is probably little different from zero. But we come back to a strange reluctance to use some simple, immutable, predetermined identifier when a more complicated, changeable, and unknown one can be used instead. I suspect that if you mandated that DUID-LL was always sent then that would satisfy most users, and the few remaining onces could work around the limitations with some workflow adjustments. Then what's the next step ? Does a device also send a different identifier ? Or do all the other options become deprecated ? PS - please don't CC me in replies. I'm on the list, if you reply to the list then I'll see the reply there. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From Ted.Lemon@nominum.com Fri Mar 16 10:26:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6365721E8035 for ; Fri, 16 Mar 2012 10:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.442 X-Spam-Level: X-Spam-Status: No, score=-106.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+sG6dsUhUJr for ; Fri, 16 Mar 2012 10:26:04 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7F44121E8034 for ; Fri, 16 Mar 2012 10:26:04 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT2N3rIj58UtBZTnqmrFF/+Q2euSD98Q4@postini.com; Fri, 16 Mar 2012 10:26:04 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 91ADD1B8310 for ; Fri, 16 Mar 2012 10:26:03 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 889B6190052; Fri, 16 Mar 2012 10:26:03 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 16 Mar 2012 10:26:03 -0700 From: Ted Lemon To: perl-list Thread-Topic: [dhcwg] DUID vs MAC address: the fight of the century! Thread-Index: AQHNA4wQylI0h3lqoU64F2JcJ4g3aZZtk2wAgAAOjAA= Date: Fri, 16 Mar 2012 17:26:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_C7B1FF7CEAC5402B917C4B25EB473C6Enominumcom_" MIME-Version: 1.0 Cc: dhcwg Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:26:05 -0000 --_000_C7B1FF7CEAC5402B917C4B25EB473C6Enominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 16, 2012, at 12:33 PM, perl-list > wrote: DUID-LL - true - the hardware address is in that one .... it cannot be gua= ranteed that method will be used by the client since there are two others. I did address that point later in the message to which you are replying... --_000_C7B1FF7CEAC5402B917C4B25EB473C6Enominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 16, 2012, at 12:33 PM, perl-list <perl-list@network1.net> wrote:
DUID-LL - true - the hardware address is in that one ....  it cannot be guara= nteed that method will be used by the client since there are two others.

I did address that point later in the message to which you are replyin= g...


--_000_C7B1FF7CEAC5402B917C4B25EB473C6Enominumcom_-- From Ted.Lemon@nominum.com Fri Mar 16 10:39:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A919C21E8043 for ; Fri, 16 Mar 2012 10:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH2JKb3dfARr for ; Fri, 16 Mar 2012 10:39:22 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 639BD21E8035 for ; Fri, 16 Mar 2012 10:39:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT2N6ykict2pVsBHmn0kgr2nvBNawbGHs@postini.com; Fri, 16 Mar 2012 10:39:22 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 957061B8310 for ; Fri, 16 Mar 2012 10:39:21 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8EF8D190052 for ; Fri, 16 Mar 2012 10:39:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 16 Mar 2012 10:39:21 -0700 From: Ted Lemon To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] DUID vs MAC address: the fight of the century! Thread-Index: AQHNA4t/ehSCa6OJu0aHIrVoEwCDt5ZtnhcAgAAHmgA= Date: Fri, 16 Mar 2012 17:39:21 +0000 Message-ID: References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> <2B88B3F1-9A2F-438A-A833-F4F5A5D9ED1E@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <21533DDE6877BF41AD84DA5982AE9576@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:39:23 -0000 On Mar 16, 2012, at 1:12 PM, Simon Hobson wrote: > That, I have to say is semantic wriggling. I wrote the text. I know what I intended it to mean. > If the DHC working group really has no interest in what users think then = I think that says a lot. Some people who are on the WG were well aware of u= sers feelings, now if that never entered any discussion I think those peopl= e involved perhaps need to consider the function and purpose of standards. The working group is interested in what all users think, not just you. > Your comment is perhaps valid, but would the current structure still work= if suddenly a *lot* of users joined the WG to air their views - rather tha= n trusting that those who are already on the WG and are fully aware of thos= e view might perhaps air them ? Participation in the working group is down. More participation would be b= etter. However, if the form the participation takes is simply "voting," t= hen it's probably better that you don't show up. > Perhaps I'm reading too much into this, and I really don't want to flog w= hat's left of this old equine carcass any more, but your attitude does sugg= est an element of "if you don't air it at the WG we don't give a about what users think or need." I hope that's not th= e case, but it is how it comes across. No, that's not my point. My point is that the fact that some ISC DHCP use= rs agree on something neither means that what they agree on represents a co= nsensus, nor that they've considered all the options. > That may be almost true, but what is equally true is that it is the least= likely DUID option to be present. My understanding (from memory, correct m= e if I'm wrong) is that on any device with persistent storage, use of DUID-= LL is deprecated in favour of one of the other options. Unless DUID-LL is p= resent from **ALL** devices, then it cannot be used to substitute for hardw= are address (or some better identifier). We can update that standard as easily as we can define a new option. So th= e question is what we want to do, not what the standard currently says. > That would probably suit *most* use cases people are talking about. To su= it *all* use cases, you'd also have to mandate that all DHCPv4 clients also= send that option. The chances of getting that passed **and** into common u= sage is probably little different from zero. Why is that? Isn't the DHCPv4 client already sending its MAC address? > But we come back to a strange reluctance to use some simple, immutable, p= redetermined identifier when a more complicated, changeable, and unknown on= e can be used instead. It's only strange because each time I explain it to you, you complain that = I'm not listening. DUID is supposed to be immutable; if it is not, it's b= ecause someone has failed to implement DHCPv6, and has instead implemented = something sort of like DHCPv6 that isn't compliant with the standard. The= reason for using a uniform identifier is that resources are allocated to t= he client on the basis of the identifier it presents, including, potentiall= y, a domain name. If the client is not consistent as to the identifier it= presents, the DHCP server will see a conflict in the use of resources such= as domain names in situations where no conflict actually exists. > I suspect that if you mandated that DUID-LL was always sent then that wou= ld satisfy most users, and the few remaining onces could work around the li= mitations with some workflow adjustments. > Then what's the next step ? Does a device also send a different identifie= r ? Or do all the other options become deprecated ? I'm proposing that if the device can send a DUID-LL, it should. If it can= 't, it can use one of the other DUIDs. I think this addresses your use ca= se without breaking the use cases that DUID was intended to address. Woul= d you be happy with this solution? > PS - please don't CC me in replies. I'm on the list, if you reply to the = list then I'll see the reply there. I'm replying to you and CCing the mailing list. I'm sorry your mail user = agent can't tell that both messages are the same message, but it gets reall= y cumbersome to constantly edit headers to satisfy requests like this, so i= t's traditional on IETF mailing lists to just accept that there will be dup= licates and not complain about it. Personally I would rather that the mai= ling list software add a Reply-To: header, but there are problems with that= , particularly since non-members frequently post to IETF mailing lists. From farmer@umn.edu Fri Mar 16 11:19:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB39921E8059 for ; Fri, 16 Mar 2012 11:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDn1rz5kvAQA for ; Fri, 16 Mar 2012 11:19:47 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1B96B21F8623 for ; Fri, 16 Mar 2012 11:19:46 -0700 (PDT) Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 16 Mar 2012 13:19:35 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR X-Umn-Classification: local Received: by mail-iy0-f171.google.com with SMTP id j38so10039039iad.16 for ; Fri, 16 Mar 2012 11:19:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=s9jBzSC05FFzysq9vM3PcimWrpa71eNJcbtOkB7C7CU=; b=Ghn2m4HUhsGGatqa+mrXnRmI+EOV9vohz00Ns8yOcHAGmmQPbYlhtzfW/Q8QQAmr6E Flt8GZz0eIX/H+TrZtu8QfKMwCuL8NP6Vxmd6L2OxvU1WxqY7i3Fodga0khYWgYjNVCG o1bCnkehuG8TKXJr95AYSXshGoYP6HIG+kBTKSyV2pTQ0CsAgUPUYq6ykj44zW8N1GZx cfoqh3FXGrZmIPQjuO1CQ7LznL32hzajXqU6+KkF8OoWjJepX76L3ERN5EOxq5Rgo78K Kv8DbZtftEOwKtxliZ80glUQ3plvoovYBZSQJMPG6z2YT5O+ZGM2C6j0HpRcIV7jfSsO 4GWQ== Received: by 10.50.216.136 with SMTP id oq8mr125028igc.63.1331921974902; Fri, 16 Mar 2012 11:19:34 -0700 (PDT) Received: from x-128-101-234-54.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:225:ff:fe43:6145]) by mx.google.com with ESMTPS id wp4sm166207igc.3.2012.03.16.11.19.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 11:19:33 -0700 (PDT) Message-ID: <4F638432.7000304@umn.edu> Date: Fri, 16 Mar 2012 13:19:30 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: perl-list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmE+F70uKuqZYsCXAXDt3W4u0XnNZ4zyVZKGV3ee4U7E46/ngzPxfIRMctChBkSodI+pszK Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:19:49 -0000 We should not back away for DUID, it was created for good reason, it is the right answer for the long term. The fundamental problem wasn't fixing the client identifier problem with DUID. The fundamental problem was thinking that DHCPv6 and DHCPv4 can be ships in the night. Most of us are not managing separate IPv6 networks and IPv4 networks that can have client identifiers that are ships in the night. We are running Dual-Stack IPv4/IPv6 networks. In the short run I believe we need a DHCPv6 relay option to included the hardware address in the information going to the DHCPv6 server, this provides network operators a partial solution to the immediate operational issues, and they can have full control of the implementation of such a solution. However, in the longer run I believe we should reexamine and maybe clearly specify what the proper Dual-Stack DHCP client behavior should be. This could include requiring DUID-LL or something like draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 on the DHCPv6 client side. It could require the use of the same DUID on the DHCPv4 client side. Personally, I think I would prefer the DHCPv6 client to include a list of all possible hardware addresses. This wouldn't require any changes to DHCPv4 client code and would still allow DUID to work as intended, while allowing correlation of all IPv4 and IPv6 addresses assigned to an individual client regardless of how many interfaces or network prefixes it is using. I'm not sure the proposal to just use DUID-LL will actually allow you to correlate all the IPv4 address of a multi-interface host. You would get all the IPv6 addresses which is why DUID was created. On 3/16/12 11:33 CDT, perl-list wrote: > > The fact is that there are definitely use cases where the MAC > address is a useful key to be used for associating the device in the > box with a back office database record. However, it's also almost > certainly true that in _every single case_ like this, DUID-LL is a > valid identifier to use. > > > > DUID-LL - true - the hardware address is in that one .... it cannot be > guaranteed that method will be used by the client since there are two > others. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From iesg-secretary@ietf.org Fri Mar 16 11:38:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A2821E8059; Fri, 16 Mar 2012 11:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Iv6AYZ6LiOb; Fri, 16 Mar 2012 11:38:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432CA21F8738; Fri, 16 Mar 2012 11:38:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120316183825.25401.75784.idtracker@ietfa.amsl.com> Date: Fri, 16 Mar 2012 11:38:25 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (DHCPv6 Redundancy Deployment Considerations) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:38:30 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv6 Redundancy Deployment Considerations' as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document documents some deployment considerations for those who wishing to use DHCPv6 to support their deployment of IPv6. Specifically, providing semi-redundant DHCPv6 services is discussed in this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-redundancy-consider/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-redundancy-consider/ballot/ No IPR declarations have been submitted directly on this I-D. From volz@cisco.com Fri Mar 16 11:42:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4ED21E806F for ; Fri, 16 Mar 2012 11:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.274 X-Spam-Level: X-Spam-Status: No, score=-8.274 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcOQh6lWiqua for ; Fri, 16 Mar 2012 11:42:19 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC1021E8065 for ; Fri, 16 Mar 2012 11:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=5625; q=dns/txt; s=iport; t=1331923336; x=1333132936; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=Lb0Vc5IBhaBWfLKQyGRkYnxibSlfNtr/AVijVBuTVGk=; b=T3CFmtSZmgDQtj7muousFczmG5P21J4iXEEjNjrgsJLQdvdQ9gdR0Nif 8Cmb4j6n2+jXgMD/DIKItyVTJYmaBZ7opnRH03oZv1aVNWuZSiCGmNxEO CT4oSPLdPclXlb7bOgd4vXx3TEonNC0llMx+a8kshTWZbaMLD98Npx0bT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4JAG6IY0+tJXHB/2dsb2JhbABChT6wdgKBB4IJAQEBAwEBAQEPARBLCwULAgEIGCoCAicwAQEEEyKHYwULmjuNBJIkBI9nM2MEiCONQ44/gWiDAg X-IronPort-AV: E=Sophos;i="4.73,599,1325462400"; d="scan'208,217";a="67139796" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 16 Mar 2012 18:42:16 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2GIgFf4016431; Fri, 16 Mar 2012 18:42:15 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 13:42:15 -0500 Received: from 72.163.62.204 ([72.163.62.204]) by XMB-RCD-101.cisco.com ([72.163.62.143]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Mar 2012 18:42:15 +0000 References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> Content-Transfer-Encoding: 7bit From: "Bernie Volz (volz)" Thread-Topic: [dhcwg] DUID vs MAC address: the fight of the century! Thread-Index: Ac0DpIHeDpY6HVfiSN+kmqiS4LseRQ== Content-Type: multipart/alternative; boundary="Apple-Mail-4A288E2D-72B8-4EBF-B037-3E062407BE29"; charset="iso-8859-1" In-Reply-To: Message-ID: <1D32C201-BEE9-4420-B593-ADFA58F2F62F@cisco.com> Date: Fri, 16 Mar 2012 14:42:14 -0400 To: "Ted Lemon" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 16 Mar 2012 18:42:15.0654 (UTC) FILETIME=[82242860:01CD03A4] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:42:21 -0000 --Apple-Mail-4A288E2D-72B8-4EBF-B037-3E062407BE29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes! I was going to suggest we look at 3315 and revise the DUID-LL descripti= on to make it more likely to be used. =46rom a quick look at some data I hav= e for a few thousand clients (mostly iphones, ipads, etc) it didn't look lik= e any where using DUID-LL which seemed a bit odd for these devices? Would an= yone replace the NIC "card" in these? Sent from my iPad On Mar 16, 2012, at 11:47 AM, "Ted Lemon" wrote: > On Mar 16, 2012, at 10:39 AM, Simon Hobson wrote:= >> Also, I think we reached a consensus that in the general case, there is n= o way to match IPv4 clients with IPv6 clients. It may be in some cases (eg b= y matching port IDs from relay agents), but in the general case IPv6 clients= will be using DUIDs which we are specifically barred from looking into even= if they did contain the same hardware address as is currently used for the i= nterface. >=20 > This was not a working group discussion; what consensus may have been reac= hed on the ISC DHCP mailing list is not a matter of interest to the working g= roup. If you want to participate in the working group, that's great, but p= lease don't present this as a fait accomplis. >=20 > The fact is that there are definitely use cases where the MAC address is a= useful key to be used for associating the device in the box with a back off= ice database record. However, it's also almost certainly true that in _eve= ry single case_ like this, DUID-LL is a valid identifier to use. >=20 > So if we really want to go down the road you're proposing, Simon, I think t= hat the right thing to do is to _require_ that DUID-LL be used instead of DU= ID-LLT in those cases where it is applicable, and to permit DHCP servers to e= xamine the link layer address contained within the DUID-LL for the purposes o= f matching records in back office databases that may have been generated by r= eading bar codes off the side of boxes. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-4A288E2D-72B8-4EBF-B037-3E062407BE29 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Yes! I was going to suggest we look at 3315 and revise the DUID-LL description to make it more likely to be used. From a quick look at some data I have for a few thousand clients (mostly iphones, ipads, etc) it didn't look like any where using DUID-LL which seemed a bit odd for these devices? Would anyone replace the NIC "card" in these?

Sent from my iPad

On Mar 16, 2012, at 11:47 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

On Mar 16, 2012, at 10:39 AM, Simon Hobson <linux@thehobsons.co.uk> wrote:
Also, I think we reached a consensus that in the general case, there is no way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by matching port IDs from relay agents), but in the general case IPv6 clients will be using DUIDs which we are specifically barred from looking into even if they did contain the same hardware address as is currently used for the interface.

This was not a working group discussion; what consensus may have been reached on the ISC DHCP mailing list is not a matter of interest to the working group.   If you want to participate in the working group, that's great, but please don't present this as a fait accomplis.

The fact is that there are definitely use cases where the MAC address is a useful key to be used for associating the device in the box with a back office database record.   However, it's also almost certainly true that in _every single case_ like this, DUID-LL is a valid identifier to use.

So if we really want to go down the road you're proposing, Simon, I think that the right thing to do is to _require_ that DUID-LL be used instead of DUID-LLT in those cases where it is applicable, and to permit DHCP servers to examine the link layer address contained within the DUID-LL for the purposes of matching records in back office databases that may have been generated by reading bar codes off the side of boxes.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
--Apple-Mail-4A288E2D-72B8-4EBF-B037-3E062407BE29-- From iesg-secretary@ietf.org Fri Mar 16 11:56:13 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1390421F85AF; Fri, 16 Mar 2012 11:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lrq9ErfAEv0p; Fri, 16 Mar 2012 11:56:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BCF21F858B; Fri, 16 Mar 2012 11:56:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120316185610.30914.54869.idtracker@ietfa.amsl.com> Date: Fri, 16 Mar 2012 11:56:10 -0700 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Virtual Subnet Selection Options for DHCPv4 and DHCPv6' to Proposed Standard (draft-ietf-dhc-vpn-option-15.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:56:13 -0000 The IESG has approved the following document: - 'Virtual Subnet Selection Options for DHCPv4 and DHCPv6' (draft-ietf-dhc-vpn-option-15.txt) as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/ Technical Summary The draft documents DHCPv4 and DHCPv6 options used by client, servers, relays, and in some cases proxies to identify the VPN that a particular request originates from. These options are intended to be used to by DHCP servers to help determine how to respond to DHCP requests. For DHCPv4 the draft defines options in agreement with [RFC3942]. Working Group Summary There was nothing controversial about this document. Document Quality At least one DHCP server supports this implementation. It is also believed that at least one client implementation exists that supports the specified options for DHCPv4. Beyond what was performed with key members of the dhc WG no special reviews were performed or required. Note that this document has been extensively revised based on previous IESG review, and a second IETF last call has been issued for this document, prior to it returning to an IESG telechat agenda. Personnel John Brzozowski (john_brzozowski@cable.comcast.com) is the document shepherd. Ralph Droms (rdroms@cisco.com) is the responsible AD. From akostur@incognito.com Fri Mar 16 12:25:27 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6049A21F869A for ; Fri, 16 Mar 2012 12:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.632 X-Spam-Level: X-Spam-Status: No, score=-5.632 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymp10LEk6xjH for ; Fri, 16 Mar 2012 12:25:26 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id F027F21F85D5 for ; Fri, 16 Mar 2012 12:25:25 -0700 (PDT) Received: from mail-lpp01m010-f41.google.com ([209.85.215.41]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT2OTpbHStysPl2sLop5I0ftE5zDluaYN@postini.com; Fri, 16 Mar 2012 12:25:26 PDT Received: by mail-lpp01m010-f41.google.com with SMTP id z14so4926673lag.14 for ; Fri, 16 Mar 2012 12:25:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MqX6NNzzN8+SyydNtfLfyBeF0Xvu0d5MscFC8S4hqnE=; b=SUljDIJ+w2Et6baY4NXEI8zpFCXygHrzDEZdDYmbAAdfkik2wMgBnyasMbONzuCqJ4 6Ba3BDAjj6SXsJEhYeFd34pFDMqa22X50MHwZTeBX8WWrQ51Ib7VNYqC26Pt8i7P4n+A VN1p8fFrqj9UXoX+DEA63eollUXVdGiEvoDVwe8YoCVwUgfx6+i1a1MjHRrMEtU/Cj2j NYMPkS3qGxUCJ5NEXynzGa2B2H/l6a0NvkjC0ZjMWH96HFEZgUYAaxZr68dXs1GRe21l 49qDfDLQUE0/Bak5dOJ4TQX/YyGDChdm3hWMoK0vXFxUWS4V6cG0MSj8pU5WthOQ5ntx sMtg== MIME-Version: 1.0 Received: by 10.112.42.7 with SMTP id j7mr1320552lbl.75.1331925924999; Fri, 16 Mar 2012 12:25:24 -0700 (PDT) Received: by 10.112.86.135 with HTTP; Fri, 16 Mar 2012 12:25:24 -0700 (PDT) In-Reply-To: <1D32C201-BEE9-4420-B593-ADFA58F2F62F@cisco.com> References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> <1D32C201-BEE9-4420-B593-ADFA58F2F62F@cisco.com> Date: Fri, 16 Mar 2012 12:25:24 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=e0cb4efa6e36a074ca04bb612b8d X-Gm-Message-State: ALoCoQkF1uvMRTpG7FALg0wY57z8KLh8p3bxK4FQDCqb5pVml5RGVtyNk2iuLO0crQ3KObPdLbUZ Cc: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 19:25:27 -0000 --e0cb4efa6e36a074ca04bb612b8d Content-Type: text/plain; charset=ISO-8859-1 Probably not, but they'd presumably be following the text that said that if the device has persistent storage, that the DUID-LLT was the preferred DUID to use. On Fri, Mar 16, 2012 at 11:42, Bernie Volz (volz) wrote: > Yes! I was going to suggest we look at 3315 and revise the DUID-LL > description to make it more likely to be used. From a quick look at some > data I have for a few thousand clients (mostly iphones, ipads, etc) it > didn't look like any where using DUID-LL which seemed a bit odd for these > devices? Would anyone replace the NIC "card" in these? > > Sent from my iPad > > On Mar 16, 2012, at 11:47 AM, "Ted Lemon" wrote: > > On Mar 16, 2012, at 10:39 AM, Simon Hobson > wrote: > > Also, I think we reached a consensus that in the general case, there is no > way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by > matching port IDs from relay agents), but in the general case IPv6 clients > will be using DUIDs which we are specifically barred from looking into even > if they did contain the same hardware address as is currently used for the > interface. > > > This was not a working group discussion; what consensus may have been > reached on the ISC DHCP mailing list is not a matter of interest to the > working group. If you want to participate in the working group, that's > great, but please don't present this as a fait accomplis. > > The fact is that there are definitely use cases where the MAC address is > a useful key to be used for associating the device in the box with a back > office database record. However, it's also almost certainly true that in > _every single case_ like this, DUID-LL is a valid identifier to use. > > So if we really want to go down the road you're proposing, Simon, I > think that the right thing to do is to _require_ that DUID-LL be used > instead of DUID-LLT in those cases where it is applicable, and to permit > DHCP servers to examine the link layer address contained within the DUID-LL > for the purposes of matching records in back office databases that may have > been generated by reading bar codes off the side of boxes. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > -- *Andre Kostur* --e0cb4efa6e36a074ca04bb612b8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Probably not, but they'd presumably be following the t= ext that said that if the device has persistent storage, that the DUID-LLT = was the preferred DUID to use.=A0

On Fri,= Mar 16, 2012 at 11:42, Bernie Volz (volz) <volz@cisco.com> wrote:
Yes! I was goi= ng to suggest we look at 3315 and revise the DUID-LL description to make it= more likely to be used. From a quick look at some data I have for a few th= ousand clients (mostly iphones, ipads, etc) it didn't look like any whe= re using DUID-LL which seemed a bit odd for these devices? Would anyone rep= lace the NIC "card" in these?

Sent from my iPad

On Mar 16, 2012,= at 11:47 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

<= div>
On Mar 16, 2012, at 10:39 AM, Simon Hobson <linux@thehobsons.co.uk> wrote:<= /div>
Also, I think we reached a consensus that in the general case, there is no way t= o match IPv4 clients with IPv6 clients. It may be in some cases (eg by matc= hing port IDs from relay agents), but in the general case IPv6 clients will= be using DUIDs which we are specifically barred from looking into even if they did contain the same hardware addres= s as is currently used for the interface.

This was not a working group discussion; what consensus may have been = reached on the ISC DHCP mailing list is not a matter of interest to the wor= king group. =A0 If you want to participate in the working group, that's= great, but please don't present this as a fait accomplis.

The fact is that there are definitely use cases where the MAC address = is a useful key to be used for associating the device in the box with a bac= k office database record. =A0 However, it's also almost certainly true = that in _every single case_ like this, DUID-LL is a valid identifier to use.

So if we really want to go down the road you're proposing, Simon, = I think that the right thing to do is to _require_ that DUID-LL be used ins= tead of DUID-LLT in those cases where it is applicable, and to permit DHCP = servers to examine the link layer address contained within the DUID-LL for the purposes of matching records in back = office databases that may have been generated by reading bar codes off the = side of boxes.

=
_______________________________________________
= dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--
<= tbody>
Andre Kostur<= /b>=A0

--e0cb4efa6e36a074ca04bb612b8d-- From Niall.oReilly@ucd.ie Fri Mar 16 13:19:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FCC21E800F for ; Fri, 16 Mar 2012 13:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtXwgkJI5fZ7 for ; Fri, 16 Mar 2012 13:19:00 -0700 (PDT) Received: from mx4.ucd.ie (mx4.ucd.ie [137.43.231.112]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9221F85A3 for ; Fri, 16 Mar 2012 13:18:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,599,1325462400"; d="scan'208";a="10773037" Received: from unknown (HELO [10.0.1.177]) ([83.141.81.52]) by smtp.ucd.ie with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 16 Mar 2012 20:18:58 +0000 Message-ID: <4F63A01D.60405@ucd.ie> Date: Fri, 16 Mar 2012 20:18:37 +0000 From: Niall O'Reilly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:19:01 -0000 On 16/03/12 14:39, Simon Hobson wrote: > On that basis, the hardware address is the least bad choice that > generally meets most admins' requirements (some permutation of c-f) - > while in the general case, only one (the least likely to be found) of > the DUID options do not. Thanks for the summary, Simon. +1 from me. Niall O'Reilly From achatz@forthnetgroup.gr Fri Mar 16 13:19:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4435121E801A for ; Fri, 16 Mar 2012 13:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WzCAAa-l4ee for ; Fri, 16 Mar 2012 13:19:35 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 55F7F21E8019 for ; Fri, 16 Mar 2012 13:19:35 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2GKJXUE013911 for ; Fri, 16 Mar 2012 22:19:33 +0200 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id q2GKJX9O025504 for ; Fri, 16 Mar 2012 22:19:33 +0200 Received: from [192.168.1.2] (194.219.107.1.dsl.dyn.forthnet.gr [194.219.107.1]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2GKJNRo025834; Fri, 16 Mar 2012 22:19:24 +0200 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4F63A045.3070300@forthnetgroup.gr> Date: Fri, 16 Mar 2012 22:19:17 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 CC: dhcwg@ietf.org References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> <1D32C201-BEE9-4420-B593-ADFA58F2F62F@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:19:36 -0000 Fyi, we met the following issue regarding the DUID: We use a common Framed-Interface-Id for our subscribers which is defined through radius and then passed to the managed CPEs. DUID-LL didn't work for us because of the WAN link-layer address being generated using the common Framed-Interface-Id. DUID-LLT didn't also work for us because if two CPEs that share a common WAN link-layer address reboot (or reset to factory defaults) at the same time, their time will be also the same. So we ended up using DUID-EN (the vendor refused to use the LAN link-layer address for DUID-LL, although i don't know if that is applicable). -- Tassos Andre Kostur wrote on 16/3/2012 21:25: > Probably not, but they'd presumably be following the text that said that if the device > has persistent storage, that the DUID-LLT was the preferred DUID to use. > > On Fri, Mar 16, 2012 at 11:42, Bernie Volz (volz) > wrote: > > Yes! I was going to suggest we look at 3315 and revise the DUID-LL description to > make it more likely to be used. From a quick look at some data I have for a few > thousand clients (mostly iphones, ipads, etc) it didn't look like any where using > DUID-LL which seemed a bit odd for these devices? Would anyone replace the NIC > "card" in these? > > Sent from my iPad > > On Mar 16, 2012, at 11:47 AM, "Ted Lemon" > wrote: > >> On Mar 16, 2012, at 10:39 AM, Simon Hobson > > wrote: >>> Also, I think we reached a consensus that in the general case, there is no way to >>> match IPv4 clients with IPv6 clients. It may be in some cases (eg by matching port >>> IDs from relay agents), but in the general case IPv6 clients will be using DUIDs >>> which we are specifically barred from looking into even if they did contain the >>> same hardware address as is currently used for the interface. >> >> This was not a working group discussion; what consensus may have been reached on >> the ISC DHCP mailing list is not a matter of interest to the working group. If >> you want to participate in the working group, that's great, but please don't >> present this as a fait accomplis. >> >> The fact is that there are definitely use cases where the MAC address is a useful >> key to be used for associating the device in the box with a back office database >> record. However, it's also almost certainly true that in _every single case_ like >> this, DUID-LL is a valid identifier to use. >> >> So if we really want to go down the road you're proposing, Simon, I think that the >> right thing to do is to _require_ that DUID-LL be used instead of DUID-LLT in those >> cases where it is applicable, and to permit DHCP servers to examine the link layer >> address contained within the DUID-LL for the purposes of matching records in back >> office databases that may have been generated by reading bar codes off the side of >> boxes. >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > -- > *Andre Kostur* > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From dankney@network1.net Fri Mar 16 13:19:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F4621E8048 for ; Fri, 16 Mar 2012 13:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqdY5HPU+kWn for ; Fri, 16 Mar 2012 13:19:46 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 88C1221E800F for ; Fri, 16 Mar 2012 13:19:46 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 9273354296C; Fri, 16 Mar 2012 16:19:45 -0400 (EDT) Date: Fri, 16 Mar 2012 16:19:45 -0400 (EDT) From: perl-list To: David Farmer Message-ID: <6399e484-43f0-4bbb-b41f-b4f9fffc505a@zimbra.network1.net> In-Reply-To: <4F638432.7000304@umn.edu> Content-Type: multipart/alternative; boundary="=_7c4773e5-1048-4056-a30a-23e121b1b3c4" MIME-Version: 1.0 X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:19:47 -0000 --=_7c4773e5-1048-4056-a30a-23e121b1b3c4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit David - you have hit the proverbial nail squarely on the head with this. That is the exact problem we are dealing with. Operators, during this time of transition/dual stacking MUST have access to the hardware address at least in some cases. I don't understand what all the animosity toward this is... I am not understanding why it wasn't included in the first place. Wouldn't more information be preferable to less? I, for one, do not think that any of the other IDs need to go away. DHCPv4 used the client id to allocate addresses. The standard provided chaddr only for informational purposes. Information is good - the more of it network operators have, the better. ----- Original Message ----- > From: "David Farmer" > To: "perl-list" > Cc: "Ted Lemon" , "dhcwg" , > "David Farmer" > Sent: Friday, March 16, 2012 2:19:30 PM > Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! > We should not back away for DUID, it was created for good reason, it > is > the right answer for the long term. The fundamental problem wasn't > fixing the client identifier problem with DUID. The fundamental > problem > was thinking that DHCPv6 and DHCPv4 can be ships in the night. > Most of us are not managing separate IPv6 networks and IPv4 networks > that can have client identifiers that are ships in the night. We are > running Dual-Stack IPv4/IPv6 networks. > In the short run I believe we need a DHCPv6 relay option to included > the > hardware address in the information going to the DHCPv6 server, this > provides network operators a partial solution to the immediate > operational issues, and they can have full control of the > implementation > of such a solution. > However, in the longer run I believe we should reexamine and maybe > clearly specify what the proper Dual-Stack DHCP client behavior > should > be. This could include requiring DUID-LL or something like > draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 on the DHCPv6 client > side. It could require the use of the same DUID on the DHCPv4 client > side. > Personally, I think I would prefer the DHCPv6 client to include a > list > of all possible hardware addresses. This wouldn't require any changes > to DHCPv4 client code and would still allow DUID to work as intended, > while allowing correlation of all IPv4 and IPv6 addresses assigned to > an > individual client regardless of how many interfaces or network > prefixes > it is using. I'm not sure the proposal to just use DUID-LL will > actually allow you to correlate all the IPv4 address of a > multi-interface host. You would get all the IPv6 addresses which is > why > DUID was created. > On 3/16/12 11:33 CDT, perl-list wrote: > > > > The fact is that there are definitely use cases where the MAC > > address is a useful key to be used for associating the device in > > the > > box with a back office database record. However, it's also almost > > certainly true that in _every single case_ like this, DUID-LL is a > > valid identifier to use. > > > > > > > > DUID-LL - true - the hardware address is in that one .... it cannot > > be > > guaranteed that method will be used by the client since there are > > two > > others. > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== --=_7c4773e5-1048-4056-a30a-23e121b1b3c4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>David - you have hit the proverbial na= il squarely on the head with this.  That is the exact problem we are d= ealing with.  Operators, during this time of transition/dual stacking = MUST have access to the hardware address at least in some cases.  I do= n't understand what all the animosity toward this is...  I am not unde= rstanding why it wasn't included in the first place.  Wouldn't more in= formation be preferable to less?  I, for one, do not think that any of= the other IDs need to go away.  DHCPv4 used the client id to allocate= addresses.  The standard provided chaddr only for informational purpo= ses.  Information is good - the more of it network operators = ;have, the better.


From: "David Farmer" <farmer@umn.edu>
To: "perl-list" <perl-= list@network1.net>
Cc: "Ted Lemon" <Ted.Lemon@nominum.com&g= t;, "dhcwg" <dhcwg@ietf.org>, "David Farmer" <farmer@umn.edu>Sent: Friday, March 16, 2012 2:19:30 PM
Subject: Re: [dh= cwg] DUID vs MAC address: the fight of the century!

We should not ba= ck away for DUID, it was created for good reason, it is
the right answe= r for the long term.  The fundamental problem wasn't
fixing the cl= ient identifier problem with DUID.  The fundamental problem
was th= inking that DHCPv6 and DHCPv4 can be ships in the night.

Most of us = are not managing separate IPv6 networks and IPv4 networks
that can have= client identifiers that are ships in the night.  We are
running D= ual-Stack IPv4/IPv6 networks.

In the short run I believe we need a D= HCPv6 relay option to included the
hardware address in the information = going to the DHCPv6 server, this
provides network operators a partial s= olution to the immediate
operational issues, and they can have full con= trol of the implementation
of such a solution.

However, in the l= onger run I believe we should reexamine and maybe
clearly specify what = the proper Dual-Stack DHCP client behavior should
be.  This could = include requiring DUID-LL or something like
draft-halwasia-dhc-dhcpv6-h= ardware-addr-opt-01 on the DHCPv6 client
side.  It could require t= he use of the same DUID on the DHCPv4 client side.

Personally, I thi= nk I would prefer the DHCPv6 client to include a list
of all possible h= ardware addresses.  This wouldn't require any changes
to DHCPv4 cl= ient code and would still allow DUID to work as intended,
while allowin= g correlation of all IPv4 and IPv6 addresses assigned to an
individual = client regardless of how many interfaces or network prefixes
it is usin= g.  I'm not sure the proposal to just use DUID-LL will
actually al= low you to correlate all the IPv4 address of a
multi-interface host. &n= bsp;You would get all the IPv6 addresses which is why
DUID was created.=

On 3/16/12 11:33 CDT, perl-list wrote:
>
>    = ; The fact is that there are definitely use cases where the MAC
> &nb= sp;   address is a useful key to be used for associating the device in= the
>     box with a back office database record. However,= it's also almost
>     certainly true that in _every singl= e case_ like this, DUID-LL is a
>     valid identifier to u= se.
>
>
>
> DUID-LL - true - the hardware address i= s in that one .... it cannot be
> guaranteed that method will be used= by the client since there are two
> others.
>
>
> = _______________________________________________
> dhcwg mailing list<= br>> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg<= br>
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
David Farmer               = Email:farmer@umn.edu
Networking & Telecommunication Services
Offi= ce of Information Technology
University of Minnesota   &n= bsp;    
2218 University Ave SE   &nb= sp;        Phone: 612-626-0815
Minneapolis= , MN 55414-3029   Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


--=_7c4773e5-1048-4056-a30a-23e121b1b3c4-- From jason.weil@twcable.com Fri Mar 16 13:23:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165B521E8017 for ; Fri, 16 Mar 2012 13:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aKBJjxLYYq2 for ; Fri, 16 Mar 2012 13:23:58 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id B44DA21E800F for ; Fri, 16 Mar 2012 13:23:57 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,599,1325480400"; d="scan'208,217";a="338538756" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 16 Mar 2012 16:23:49 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 16 Mar 2012 16:23:56 -0400 From: "Weil, Jason" To: "Bernie Volz (volz)" , Ted Lemon Date: Fri, 16 Mar 2012 16:23:54 -0400 Thread-Topic: [dhcwg] DUID vs MAC address: the fight of the century! Thread-Index: Ac0DpIHeDpY6HVfiSN+kmqiS4LseRQADWEmA Message-ID: <17D514DF62ADFB47B2574E64676BAF86BAB16876@PRVPEXVS12.corp.twcable.com> References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> <1D32C201-BEE9-4420-B593-ADFA58F2F62F@cisco.com> In-Reply-To: <1D32C201-BEE9-4420-B593-ADFA58F2F62F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_17D514DF62ADFB47B2574E64676BAF86BAB16876PRVPEXVS12corpt_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:23:59 -0000 --_000_17D514DF62ADFB47B2574E64676BAF86BAB16876PRVPEXVS12corpt_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhY3R1YWxseSBwcmVmZXIgRFVJRC1MTCBhbmQgSSBrbm93IG9mIG1hbnkgaG9tZSBnYXRld2F5 cyB0aGF0IHdpbGwgYmUgYmFzZWQgb24gdGhpcyBvcHRpb24uIFRoYXQgYmVpbmcgc2FpZCB0aGVy ZSBhcmUgYSBjb3VwbGUgb2Ygb3B0aW9ucyBhbGxvd2VkIGluIHRoZSBDYWJsZWxhYnMgZVJvdXRl ciBzcGVjIGFzIHNob3duIGJlbG93LiBZb3Ugd2lsbCBub3RpY2UgdGhlIG9uZSB0aGF0IGlzIG5v dCBhbiBvcHRpb24gaXMgRFVJRC1MTFQuDQoNCkphc29uDQoNCkZyb20gZVJPVVRFUiBTcGVjOg0K DQpBIENsaWVudCBJZGVudGlmaWVyIG9wdGlvbiBjb250YWluaW5nIHRoZSBESENQIFVuaXF1ZSBJ ZGVudGlmaWVyIChEVUlEKSBmb3IgdGhpcyBlUm91dGVyIChhcyBzcGVjaWZpZWQgYnkNCltSRkMg MzMxNV0pLCB0aGUgRFVJRCBzaG91bGQgYmUgZm9ybWF0dGVkIGFzIGZvbGxvd3M6DQphLiBUaGUg ZVJvdXRlciBNVVNUIHVzZSBhIERVSUQgdGhhdCBpcyBvbmUgb2YgRFVJRC1MTCwgRFVJRC1FTiBv ciBEVUlEX1VVSUQgdHlwZSBhbmQ7DQpiLiBUaGUgZVJvdXRlciBNVVNUIHVzZSBhIERVSUQgdGhh dCBpcyBwZXJzaXN0ZW50IGFjcm9zcyBhZG1pbmlzdHJhdGl2ZSByZXNldCBvciByZWJvb3QgZm9s bG93aW5nIGEgbG9zcyBvZg0KcG93ZXIgcGVyIFtSRkMgNjIwNF0gVy02Lg0KDQoNCkZyb206IGRo Y3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQmVybmllIFZvbHogKHZvbHopDQpTZW50OiBGcmlkYXksIE1hcmNoIDE2LCAyMDEy IDI6NDIgUE0NClRvOiBUZWQgTGVtb24NCkNjOiBkaGN3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtkaGN3Z10gRFVJRCB2cyBNQUMgYWRkcmVzczogdGhlIGZpZ2h0IG9mIHRoZSBjZW50dXJ5IQ0K DQpZZXMhIEkgd2FzIGdvaW5nIHRvIHN1Z2dlc3Qgd2UgbG9vayBhdCAzMzE1IGFuZCByZXZpc2Ug dGhlIERVSUQtTEwgZGVzY3JpcHRpb24gdG8gbWFrZSBpdCBtb3JlIGxpa2VseSB0byBiZSB1c2Vk LiBGcm9tIGEgcXVpY2sgbG9vayBhdCBzb21lIGRhdGEgSSBoYXZlIGZvciBhIGZldyB0aG91c2Fu ZCBjbGllbnRzIChtb3N0bHkgaXBob25lcywgaXBhZHMsIGV0YykgaXQgZGlkbid0IGxvb2sgbGlr ZSBhbnkgd2hlcmUgdXNpbmcgRFVJRC1MTCB3aGljaCBzZWVtZWQgYSBiaXQgb2RkIGZvciB0aGVz ZSBkZXZpY2VzPyBXb3VsZCBhbnlvbmUgcmVwbGFjZSB0aGUgTklDICJjYXJkIiBpbiB0aGVzZT8N Cg0KU2VudCBmcm9tIG15IGlQYWQNCg0KT24gTWFyIDE2LCAyMDEyLCBhdCAxMTo0NyBBTSwgIlRl ZCBMZW1vbiIgPFRlZC5MZW1vbkBub21pbnVtLmNvbTxtYWlsdG86VGVkLkxlbW9uQG5vbWludW0u Y29tPj4gd3JvdGU6DQpPbiBNYXIgMTYsIDIwMTIsIGF0IDEwOjM5IEFNLCBTaW1vbiBIb2Jzb24g PGxpbnV4QHRoZWhvYnNvbnMuY28udWs8bWFpbHRvOmxpbnV4QHRoZWhvYnNvbnMuY28udWs+PiB3 cm90ZToNCkFsc28sIEkgdGhpbmsgd2UgcmVhY2hlZCBhIGNvbnNlbnN1cyB0aGF0IGluIHRoZSBn ZW5lcmFsIGNhc2UsIHRoZXJlIGlzIG5vIHdheSB0byBtYXRjaCBJUHY0IGNsaWVudHMgd2l0aCBJ UHY2IGNsaWVudHMuIEl0IG1heSBiZSBpbiBzb21lIGNhc2VzIChlZyBieSBtYXRjaGluZyBwb3J0 IElEcyBmcm9tIHJlbGF5IGFnZW50cyksIGJ1dCBpbiB0aGUgZ2VuZXJhbCBjYXNlIElQdjYgY2xp ZW50cyB3aWxsIGJlIHVzaW5nIERVSURzIHdoaWNoIHdlIGFyZSBzcGVjaWZpY2FsbHkgYmFycmVk IGZyb20gbG9va2luZyBpbnRvIGV2ZW4gaWYgdGhleSBkaWQgY29udGFpbiB0aGUgc2FtZSBoYXJk d2FyZSBhZGRyZXNzIGFzIGlzIGN1cnJlbnRseSB1c2VkIGZvciB0aGUgaW50ZXJmYWNlLg0KDQpU aGlzIHdhcyBub3QgYSB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb247IHdoYXQgY29uc2Vuc3VzIG1h eSBoYXZlIGJlZW4gcmVhY2hlZCBvbiB0aGUgSVNDIERIQ1AgbWFpbGluZyBsaXN0IGlzIG5vdCBh IG1hdHRlciBvZiBpbnRlcmVzdCB0byB0aGUgd29ya2luZyBncm91cC4gICBJZiB5b3Ugd2FudCB0 byBwYXJ0aWNpcGF0ZSBpbiB0aGUgd29ya2luZyBncm91cCwgdGhhdCdzIGdyZWF0LCBidXQgcGxl YXNlIGRvbid0IHByZXNlbnQgdGhpcyBhcyBhIGZhaXQgYWNjb21wbGlzLg0KDQpUaGUgZmFjdCBp cyB0aGF0IHRoZXJlIGFyZSBkZWZpbml0ZWx5IHVzZSBjYXNlcyB3aGVyZSB0aGUgTUFDIGFkZHJl c3MgaXMgYSB1c2VmdWwga2V5IHRvIGJlIHVzZWQgZm9yIGFzc29jaWF0aW5nIHRoZSBkZXZpY2Ug aW4gdGhlIGJveCB3aXRoIGEgYmFjayBvZmZpY2UgZGF0YWJhc2UgcmVjb3JkLiAgIEhvd2V2ZXIs IGl0J3MgYWxzbyBhbG1vc3QgY2VydGFpbmx5IHRydWUgdGhhdCBpbiBfZXZlcnkgc2luZ2xlIGNh c2VfIGxpa2UgdGhpcywgRFVJRC1MTCBpcyBhIHZhbGlkIGlkZW50aWZpZXIgdG8gdXNlLg0KDQpT byBpZiB3ZSByZWFsbHkgd2FudCB0byBnbyBkb3duIHRoZSByb2FkIHlvdSdyZSBwcm9wb3Npbmcs IFNpbW9uLCBJIHRoaW5rIHRoYXQgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGlzIHRvIF9yZXF1aXJl XyB0aGF0IERVSUQtTEwgYmUgdXNlZCBpbnN0ZWFkIG9mIERVSUQtTExUIGluIHRob3NlIGNhc2Vz IHdoZXJlIGl0IGlzIGFwcGxpY2FibGUsIGFuZCB0byBwZXJtaXQgREhDUCBzZXJ2ZXJzIHRvIGV4 YW1pbmUgdGhlIGxpbmsgbGF5ZXIgYWRkcmVzcyBjb250YWluZWQgd2l0aGluIHRoZSBEVUlELUxM IGZvciB0aGUgcHVycG9zZXMgb2YgbWF0Y2hpbmcgcmVjb3JkcyBpbiBiYWNrIG9mZmljZSBkYXRh YmFzZXMgdGhhdCBtYXkgaGF2ZSBiZWVuIGdlbmVyYXRlZCBieSByZWFkaW5nIGJhciBjb2RlcyBv ZmYgdGhlIHNpZGUgb2YgYm94ZXMuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5nIGxpc3QNCmRoY3dnQGlldGYub3JnPG1haWx0 bzpkaGN3Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGhjd2cNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgRS1tYWlsIGFu ZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWws IG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4g VGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlm aWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0 aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMg dG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdp bmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K --_000_17D514DF62ADFB47B2574E64676BAF86BAB16876PRVPEXVS12corpt_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYWN0dWFsbHkgcHJlZmVyIERVSUQtTEwgYW5kIEkga25vdyBvZiBtYW55 IGhvbWUgZ2F0ZXdheXMgdGhhdCB3aWxsIGJlIGJhc2VkIG9uIHRoaXMgb3B0aW9uLiBUaGF0IGJl aW5nIHNhaWQgdGhlcmUgYXJlIGEgY291cGxlIG9mIG9wdGlvbnMgYWxsb3dlZCBpbiB0aGUgQ2Fi bGVsYWJzDQogZVJvdXRlciBzcGVjIGFzIHNob3duIGJlbG93LiBZb3Ugd2lsbCBub3RpY2UgdGhl IG9uZSB0aGF0IGlzIG5vdCBhbiBvcHRpb24gaXMgRFVJRC1MTFQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KYXNvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+RnJvbSBlUk9VVEVSIFNwZWM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QSBD bGllbnQgSWRlbnRpZmllciBvcHRpb24gY29udGFpbmluZyB0aGUgREhDUCBVbmlxdWUgSWRlbnRp ZmllciAoRFVJRCkgZm9yIHRoaXMgZVJvdXRlciAoYXMgc3BlY2lmaWVkIGJ5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5bUkZDIDMzMTVdKSwgdGhlIERVSUQg c2hvdWxkIGJlIGZvcm1hdHRlZCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+YS4gVGhlIGVSb3V0ZXIgTVVTVCB1c2UgYSBEVUlEIHRoYXQg aXMgb25lIG9mIERVSUQtTEwsIERVSUQtRU4gb3IgRFVJRF9VVUlEIHR5cGUgYW5kOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Yi4gVGhlIGVSb3V0ZXIgTVVT VCB1c2UgYSBEVUlEIHRoYXQgaXMgcGVyc2lzdGVudCBhY3Jvc3MgYWRtaW5pc3RyYXRpdmUgcmVz ZXQgb3IgcmVib290IGZvbGxvd2luZyBhIGxvc3Mgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+cG93ZXIg cGVyIFtSRkMgNjIwNF0gVy02Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuaWUgVm9seiAodm9seik8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAxNiwgMjAxMiAyOjQyIFBNPGJyPg0KPGI+VG86PC9i PiBUZWQgTGVtb248YnI+DQo8Yj5DYzo8L2I+IGRoY3dnQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbZGhjd2ddIERVSUQgdnMgTUFDIGFkZHJlc3M6IHRoZSBmaWdodCBvZiB0aGUg Y2VudHVyeSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+WWVzISBJIHdhcyBnb2luZyB0byBzdWdnZXN0IHdlIGxvb2sgYXQgMzMxNSBhbmQgcmV2 aXNlIHRoZSBEVUlELUxMIGRlc2NyaXB0aW9uIHRvIG1ha2UgaXQgbW9yZSBsaWtlbHkgdG8gYmUg dXNlZC4gRnJvbSBhIHF1aWNrIGxvb2sgYXQgc29tZSBkYXRhIEkgaGF2ZSBmb3IgYSBmZXcgdGhv dXNhbmQgY2xpZW50cyAobW9zdGx5IGlwaG9uZXMsIGlwYWRzLCBldGMpIGl0IGRpZG4ndCBsb29r IGxpa2UgYW55IHdoZXJlDQogdXNpbmcgRFVJRC1MTCB3aGljaCBzZWVtZWQgYSBiaXQgb2RkIGZv ciB0aGVzZSBkZXZpY2VzPyBXb3VsZCBhbnlvbmUgcmVwbGFjZSB0aGUgTklDICZxdW90O2NhcmQm cXVvdDsgaW4gdGhlc2U/PGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQYWQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KT24gTWFyIDE2LCAyMDEyLCBhdCAxMTo0NyBBTSwgJnF1b3Q7VGVk IExlbW9uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86VGVkLkxlbW9uQG5vbWludW0uY29tIj5U ZWQuTGVtb25Abm9taW51bS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMTYs IDIwMTIsIGF0IDEwOjM5IEFNLCBTaW1vbiBIb2Jzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsaW51 eEB0aGVob2Jzb25zLmNvLnVrIj5saW51eEB0aGVob2Jzb25zLmNvLnVrPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFsc28sIEkgdGhpbmsgd2UgcmVhY2hl ZCBhIGNvbnNlbnN1cyB0aGF0IGluIHRoZSBnZW5lcmFsIGNhc2UsIHRoZXJlIGlzIG5vIHdheSB0 byBtYXRjaCBJUHY0IGNsaWVudHMgd2l0aCBJUHY2IGNsaWVudHMuIEl0IG1heSBiZSBpbiBzb21l IGNhc2VzIChlZyBieSBtYXRjaGluZw0KIHBvcnQgSURzIGZyb20gcmVsYXkgYWdlbnRzKSwgYnV0 IGluIHRoZSBnZW5lcmFsIGNhc2UgSVB2NiBjbGllbnRzIHdpbGwgYmUgdXNpbmcgRFVJRHMgd2hp Y2ggd2UgYXJlIHNwZWNpZmljYWxseSBiYXJyZWQgZnJvbSBsb29raW5nIGludG8gZXZlbiBpZiB0 aGV5IGRpZCBjb250YWluIHRoZSBzYW1lIGhhcmR3YXJlIGFkZHJlc3MgYXMgaXMgY3VycmVudGx5 IHVzZWQgZm9yIHRoZSBpbnRlcmZhY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdhcyBub3QgYSB3b3JraW5nIGdyb3Vw IGRpc2N1c3Npb247IHdoYXQgY29uc2Vuc3VzIG1heSBoYXZlIGJlZW4gcmVhY2hlZCBvbiB0aGUg SVNDIERIQ1AgbWFpbGluZyBsaXN0IGlzIG5vdCBhIG1hdHRlciBvZiBpbnRlcmVzdCB0byB0aGUg d29ya2luZyBncm91cC4gJm5ic3A7IElmIHlvdSB3YW50IHRvIHBhcnRpY2lwYXRlIGluIHRoZSB3 b3JraW5nIGdyb3VwLCB0aGF0J3MgZ3JlYXQsIGJ1dCBwbGVhc2UgZG9uJ3QNCiBwcmVzZW50IHRo aXMgYXMgYSBmYWl0IGFjY29tcGxpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZhY3QgaXMgdGhhdCB0aGVyZSBhcmUgZGVmaW5pdGVs eSB1c2UgY2FzZXMgd2hlcmUgdGhlIE1BQyBhZGRyZXNzIGlzIGEgdXNlZnVsIGtleSB0byBiZSB1 c2VkIGZvciBhc3NvY2lhdGluZyB0aGUgZGV2aWNlIGluIHRoZSBib3ggd2l0aCBhIGJhY2sgb2Zm aWNlIGRhdGFiYXNlIHJlY29yZC4gJm5ic3A7IEhvd2V2ZXIsIGl0J3MgYWxzbyBhbG1vc3QgY2Vy dGFpbmx5IHRydWUgdGhhdCBpbiBfZXZlcnkgc2luZ2xlDQogY2FzZV8gbGlrZSB0aGlzLCBEVUlE LUxMIGlzIGEgdmFsaWQgaWRlbnRpZmllciB0byB1c2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGlmIHdlIHJlYWxseSB3YW50IHRvIGdv IGRvd24gdGhlIHJvYWQgeW91J3JlIHByb3Bvc2luZywgU2ltb24sIEkgdGhpbmsgdGhhdCB0aGUg cmlnaHQgdGhpbmcgdG8gZG8gaXMgdG8gX3JlcXVpcmVfIHRoYXQgRFVJRC1MTCBiZSB1c2VkIGlu c3RlYWQgb2YgRFVJRC1MTFQgaW4gdGhvc2UgY2FzZXMgd2hlcmUgaXQgaXMgYXBwbGljYWJsZSwg YW5kIHRvIHBlcm1pdCBESENQIHNlcnZlcnMgdG8gZXhhbWluZSB0aGUNCiBsaW5rIGxheWVyIGFk ZHJlc3MgY29udGFpbmVkIHdpdGhpbiB0aGUgRFVJRC1MTCBmb3IgdGhlIHB1cnBvc2VzIG9mIG1h dGNoaW5nIHJlY29yZHMgaW4gYmFjayBvZmZpY2UgZGF0YWJhc2VzIHRoYXQgbWF5IGhhdmUgYmVl biBnZW5lcmF0ZWQgYnkgcmVhZGluZyBiYXIgY29kZXMgb2ZmIHRoZSBzaWRlIG9mIGJveGVzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ciPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJH cmF5IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRo ZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMg RS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_17D514DF62ADFB47B2574E64676BAF86BAB16876PRVPEXVS12corpt_-- From Niall.oReilly@ucd.ie Fri Mar 16 13:27:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1F721E8048 for ; Fri, 16 Mar 2012 13:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy+auNNbrHcE for ; Fri, 16 Mar 2012 13:27:50 -0700 (PDT) Received: from smtp.ucd.ie (mgmtirp1.ucd.ie [137.43.231.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0A821E800F for ; Fri, 16 Mar 2012 13:27:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,599,1325462400"; d="scan'208";a="13920796" Received: from unknown (HELO [10.0.1.177]) ([83.141.81.52]) by smtp.ucd.ie with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 16 Mar 2012 20:27:49 +0000 Message-ID: <4F63A239.6010306@ucd.ie> Date: Fri, 16 Mar 2012 20:27:37 +0000 From: Niall O'Reilly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:27:51 -0000 On 16/03/12 15:47, Ted Lemon wrote: > So if we really want to go down the road you're proposing, Simon, I > think that the right thing to do is to _require_ that DUID-LL be used > instead of DUID-LLT in those cases where it is applicable, and to permit > DHCP servers to examine the link layer address contained within the > DUID-LL for the purposes of matching records in back office databases > that may have been generated by reading bar codes off the side of boxes. That solution appeals to me. Niall O'Reilly From linux@thehobsons.co.uk Fri Mar 16 13:31:04 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462C521F85AF for ; Fri, 16 Mar 2012 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyHJRz12z4Dm for ; Fri, 16 Mar 2012 13:31:03 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF9C21F857A for ; Fri, 16 Mar 2012 13:31:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id B217C10401A for ; Fri, 16 Mar 2012 20:31:00 +0000 (GMT) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbhZhD43WDIO for ; Fri, 16 Mar 2012 20:31:00 +0000 (GMT) Received: from simon.thehobsons.co.uk (simons-macbookpro.thehobsons.co.uk [192.168.0.202]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 459D129F16 for ; Fri, 16 Mar 2012 20:31:00 +0000 (GMT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4F638432.7000304@umn.edu> References: <4F638432.7000304@umn.edu> Date: Fri, 16 Mar 2012 20:30:52 +0000 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:31:04 -0000 Ted Lemon wrote: > > If the DHC working group really has no interest in what users >think then I think that says a lot. Some people who are on the WG >were well aware of users feelings, now if that never entered any >discussion I think those people involved perhaps need to consider >the function and purpose of standards. > >The working group is interested in what all users think, not just you. > >> Your comment is perhaps valid, but would the current structure >>still work if suddenly a *lot* of users joined the WG to air their >>views - rather than trusting that those who are already on the WG >>and are fully aware of those view might perhaps air them ? > >Participation in the working group is down. More participation >would be better. However, if the form the participation takes is >simply "voting," then it's probably better that you don't show up. > >> Perhaps I'm reading too much into this, and I really don't want to >>flog what's left of this old equine carcass any more, but your >>attitude does suggest an element of "if you don't air it at the WG >>we don't give a about what users >>think or need." I hope that's not the case, but it is how it comes >>across. > >No, that's not my point. My point is that the fact that some ISC >DHCP users agree on something neither means that what they agree on >represents a consensus, nor that they've considered all the options. Well sticking to the specific point, there was a LOT of discussion, I do believe all options were raised, and as I recall the summary, there was at the very least a general agreement along the lines that similar to the hardware option in DHCPv4 was required for many usage cases, and having it was unlikely to break things for those who don't need it. So what's being discussed isn't just a case of "what I want" - it's clear from the length of this thread that a significant proportion of other users "want" this. I can't speak for anyone else, but I do not have the time spare to make a good contribution - hence trying to stay out of the way. As you suggest, I doubt I could make a particularly positive contribution by joining the WG. Lest it be thought that I don't value the time and effort people are putting in (including by yourself), I can assure you that is not the case. >Why is that? Isn't the DHCPv4 client already sending its MAC address? Yes, a DHCPv4 client does send it's MAC address. But, according to RFC3315, we are explicitly not allowed to compare that with a DUID : >Clients and servers MUST treat DUIDs as opaque values and MUST only >compare DUIDs for equality. Clients and servers MUST NOT in any >other way interpret DUIDs. As I read that, it says we can compare a DUID with another DUID for equality. Although we know that a DUID-LL contains the hardware address, we are expressly forbidden from extracting it and comparing with (say) a hardware address from elsewhere. A DUID-LL value will **always** fail an equality test with a DHCPv4 Hardware Address field - 2 octet DUID type, plus 2 octet hardware type, plus hardware address vs 1 byte hardware type plus hardware address. It may not be what you intended, but that is what is written in RFC 3315. Some rewording could fix that, but would then dilute the message on GUIDs being opaque. But in any case, DUID-LL may not be the same as the Hardware Address sent by a DHCPv4 client on the same interface. > > But we come back to a strange reluctance to use some simple, >immutable, predetermined identifier when a more complicated, >changeable, and unknown one can be used instead. > >It's only strange because each time I explain it to you, you >complain that I'm not listening. DUID is supposed to be immutable; >if it is not, it's because someone has failed to implement DHCPv6, >and has instead implemented something sort of like DHCPv6 that isn't >compliant with the standard. No, that is **NOT** true. I'm sorry, and I'm really really trying hard not to be argumentative, but others have also pointed out the fallacy of this. On ANY desktop system, if your user wipes their system and installs a fresh installation (of the same or a different OS) then the DUID* will most likely change - even a DUID-LL may change. Having a system which runs multiple OSs is most likely to result in different GUIDs* in the different OSs. Having a system that netboots (eg PXE followed by a full OS) will most likely mean different GUID*s. In the general case, to have these different setups all use the same persistent GUID means operator/admin intervention - to save the DUID and/or copy it from one system to another. * Unless using DUID-LL, and even that may change if the hardware has changed or the clients choose different interfaces as a base. And, you keep refusing to see (or accept) that a DUID-LLT is not known before the OS has booted and generated it. A DUID-EN probably is, hopefully that would be printed on the box in future. My experience is that changes to the (fixed) networking hardware is quite rare these days - certainly far less common than the software changes I've pointed out. Even wireless is less volatile than it used to be since so many systems have that built in as well. None of that will change without a standardised and ubiquitous machine level storage where a DUID can be put which will be completely independent of OS changes/re-installs etc. If such a facility came to pass, then that could remove much of the case for something "like a hardware address" in the DHCP packets - at least for DHCPv6 clients. In fact, such a ubiquitous and unique identifier would solve many other ID problems - not just DHCP clients. And yes, you would be right to point out that this also applies to things like SSH keys etc. >I'm proposing that if the device can send a DUID-LL, it should. If >it can't, it can use one of the other DUIDs. I think this >addresses your use case without breaking the use cases that DUID was >intended to address. Would you be happy with this solution? It would for me - I think. I'm struggling to think of any situations where a DUID-LL isn't possible (no hardware address) but the issue applies. It does still leave the issue of where DUID-LL doesn't match the Hardware Address - which will apply to 50% of interfaces on dual-interface devices, 66% of interfaces on triple-interface devices, etc. Most devices I deal with (and this applies to) are single interface - though even that is getting less common with wireless becoming common on printers. David Farmer wrote: >We should not back away for DUID, it was created for good reason, it >is the right answer for the long term. The fundamental problem >wasn't fixing the client identifier problem with DUID. The >fundamental problem was thinking that DHCPv6 and DHCPv4 can be ships >in the night. > >Most of us are not managing separate IPv6 networks and IPv4 networks >that can have client identifiers that are ships in the night. We >are running Dual-Stack IPv4/IPv6 networks. I think that is a good summary of the problem. But it's not just DHCP - many workflows have a requirement for a device identifier, which in many cases can be a hardware address when that's already being used for part of the network control/admin. >However, in the longer run I believe we should reexamine and maybe >clearly specify what the proper Dual-Stack DHCP client behavior >should be. Yes. However, there is the fundamental problem that you stand little chance now of changing common DHCPv4 client behavior - there are just too many devices (particularly embedded ones) which will never be changed*. Stuff like desktops and smartphones/tablets/etc might change, but even that's not guaranteed**. It would be great to end up in a world where all new devices come with on the back and on the outside of the packaging **AND** available in a standardised way to any software running on it. Some systems can have their asset tag (manufacturer serial number) read through software (effectively analogous to DUID-EN) - but that is not ubiquitous, nor I suspect standardised in implementation. A typical use-case for me is (eg) getting a new printer in through the door, bung it's ID into my config, and when it's plugged in it will appear on the network at the address I want. I wouldn't necessarily see the printer if it was at a different site - so getting the user to give me it's ID would be sufficient - otherwise I'd have to (for example) trawl the DHCP logs to find it (and then wait for it to change it's settings). From comments, I believe that is far from a unique situation. At present, hardware address is probably the least bad identifier. Other than DUID-LL, non of the others is immutable, nor are any of them known in advance (and so cannot be put either on the equipment or it's packaging). * Even on my small network, I have multiple devices which are "out of support" and for which there will not be any firmware updates. ** Look at the trouble Microsoft have had persuading people to leave Windows XP behind. And (through work) I still know of clients running Win98 and Mac OS 9 ! True that's not a large proportion, but usually the network problems are caused by the minority of devices. Bernie Volz (volz) wrote: >From a quick look at some data I have for a few thousand clients >(mostly iphones, ipads, etc) it didn't look like any where using >DUID-LL which seemed a bit odd for these devices? Would anyone >replace the NIC "card" in these? But they have persistent storage. From RFC 3315 : >DUID-LL is recommended for devices that ... do not have nonvolatile, >writable stable storage. While it does not say they cannot use it, it is suggestive that they should use a different type because they have a means of storing it. Out of interest, what types are most devices using ? I'm guessing DUID-LLT is most common ? Perhaps DUID-EN for some types. PS - I don't think the title is quite right. This isn't a fight for one *OR* the other. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From Niall.oReilly@ucd.ie Fri Mar 16 13:45:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2846521E8024 for ; Fri, 16 Mar 2012 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-rOZhPnrsej for ; Fri, 16 Mar 2012 13:45:29 -0700 (PDT) Received: from smtp.ucd.ie (zebra.ucd.ie [137.43.231.111]) by ietfa.amsl.com (Postfix) with ESMTP id 56BFE21E800C for ; Fri, 16 Mar 2012 13:45:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,599,1325462400"; d="scan'208";a="13921373" Received: from unknown (HELO [10.0.1.177]) ([83.141.81.52]) by smtp.ucd.ie with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 16 Mar 2012 20:45:28 +0000 Message-ID: <4F63A65D.90701@ucd.ie> Date: Fri, 16 Mar 2012 20:45:17 +0000 From: Niall O'Reilly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <4F638432.7000304@umn.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:45:30 -0000 On 16/03/12 20:30, Simon Hobson wrote: > PS - I don't think the title is quite right. This isn't a fight for one > *OR* the other. Absolutely! /Niall From Niall.oReilly@ucd.ie Fri Mar 16 14:33:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A8B21F8607 for ; Fri, 16 Mar 2012 14:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXdDdrm-wHOW for ; Fri, 16 Mar 2012 14:33:14 -0700 (PDT) Received: from mx4.ucd.ie (angel.ucd.ie [137.43.231.112]) by ietfa.amsl.com (Postfix) with ESMTP id 919C021F8606 for ; Fri, 16 Mar 2012 14:33:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,600,1325462400"; d="scan'208";a="10775190" Received: from unknown (HELO [10.0.1.177]) ([83.141.81.52]) by smtp.ucd.ie with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 16 Mar 2012 21:33:13 +0000 Message-ID: <4F63B18D.4070505@ucd.ie> Date: Fri, 16 Mar 2012 21:33:01 +0000 From: Niall O'Reilly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <2e84da15-c436-48b3-97a3-a3b02482dbd4@zimbra.network1.net> <17edc9d0-64ab-42ea-b597-57a15c23212a@zimbra.network1.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1D60@XMB-RCD-109.cisco.com> <4F63A01D.60405@ucd.ie> In-Reply-To: <4F63A01D.60405@ucd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] IETF83 dhcwg agenda items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:33:15 -0000 On 16/03/12 20:18, Niall O'Reilly wrote: > +1 from me. Not a one-liner this time. I haven't seen mention of eduroam as a use case, so here goes. Eduroam is an important use-case for us, and likely also for a sizeable (http://www.eduroamus.org/eduroam_international_map) and growing higher education enterprise-network community. We need to be able to identify IP addresses of whichever family with individual customers, and to be able to review that identification retrospectively for a number of months. We have a pair of transactions which we need to associate: authentication for access to the network, and address assignment for effective use of that network. Today, logs from the radius server used for 802.1x authentication and from the DHCP (v4) server can be joined using the hardware address. An opaque identifier, such as seems to be preferred for DHCPv6 obstructs this kind of administrative interoperation between authentication and address-assignment protocols. We're not planning to redesign our 802.1x infrastructure. We could invent a work-around by triggering some kind of complementary transaction (using SNMP perhaps) whenever a lease is committed, but that would be egregiously clumsy compared to having the DHCP transaction just carry the data we need. Best regards, Naill O'Reilly From Ted.Lemon@nominum.com Fri Mar 16 14:41:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7F421F86C7 for ; Fri, 16 Mar 2012 14:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.447 X-Spam-Level: X-Spam-Status: No, score=-106.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThR9OuUic4ZJ for ; Fri, 16 Mar 2012 14:41:29 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B5E2821F86C2 for ; Fri, 16 Mar 2012 14:41:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT2OziA0DAvjQXnSmNNViksx56iplz9Rk@postini.com; Fri, 16 Mar 2012 14:41:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B896D1B8306 for ; Fri, 16 Mar 2012 14:41:27 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id ABB90190052 for ; Fri, 16 Mar 2012 14:41:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 16 Mar 2012 14:41:21 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] DUID vs MAC address: the fight of the century! Thread-Index: AQHNA4wQylI0h3lqoU64F2JcJ4g3aZZtk2wAgAAdfACAACS0AIAAE7KA Date: Fri, 16 Mar 2012 21:41:21 +0000 Message-ID: <03B2E053-D171-4721-8B4F-0DC679E69736@nominum.com> References: <4F638432.7000304@umn.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_03B2E053D17147218B4F0DC679E69736nominumcom_" MIME-Version: 1.0 Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:41:29 -0000 --_000_03B2E053D17147218B4F0DC679E69736nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 16, 2012, at 4:30 PM, Simon Hobson > wrote: It would for me - I think. I'm struggling to think of any situations where = a DUID-LL isn't possible (no hardware address) but the issue applies. It do= es still leave the issue of where DUID-LL doesn't match the Hardware Addres= s - which will apply to 50% of interfaces on dual-interface devices, 66% of= interfaces on triple-interface devices, etc. Most devices I deal with (and= this applies to) are single interface - though even that is getting less c= ommon with wireless becoming common on printers. This doesn't matter for the box scanning case, because typically if there a= re multiple fixed network interfaces in a device, the box it comes in will = list the MAC addresses of each interface, not just one. So the case where= it fails is the DHCPv4<->DHCPv6 identification scenario. I think this argues pretty strongly for the relay agent option, despite the= patent. --_000_03B2E053D17147218B4F0DC679E69736nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 16, 2012, at 4:30 PM, Simon Hobson <linux@thehobsons.co.uk>
 wrote:
I= t would for me - I think. I'm struggling to think of any situations where a = DUID-LL isn't possible (no hardware address) but the issue applies. It does= still leave the issue of where DUID-LL doesn't match the Hardware Address = - which will apply to 50% of interfaces on dual-interface devices, 66% of interfaces on triple-interface devices, = etc. Most devices I deal with (and this applies to) are single interface - = though even that is getting less common with wireless becoming common on pr= inters.

This doesn't matter for the box scanning case, because typically if th= ere are multiple fixed network interfaces in a device, the box it comes in = will list the MAC addresses of each interface, not just one.   So the = case where it fails is the DHCPv4<->DHCPv6 identification scenario.

I think this argues pretty strongly for the relay agent option, despit= e the patent.

--_000_03B2E053D17147218B4F0DC679E69736nominumcom_-- From sthaug@nethelp.no Sat Mar 17 01:41:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4421F86EA for ; Sat, 17 Mar 2012 01:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTdHYqnBzjRK for ; Sat, 17 Mar 2012 01:41:11 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 829A021F85CD for ; Sat, 17 Mar 2012 01:41:11 -0700 (PDT) Received: (qmail 43059 invoked from network); 17 Mar 2012 08:41:09 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Mar 2012 08:41:09 -0000 Date: Sat, 17 Mar 2012 09:41:09 +0100 (CET) Message-Id: <20120317.094109.74711218.sthaug@nethelp.no> To: linux@thehobsons.co.uk From: sthaug@nethelp.no In-Reply-To: References: <4F638432.7000304@umn.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 08:41:12 -0000 > PS - I don't think the title is quite right. This isn't a fight for > one *OR* the other. Absolutely agreed. And +1 on your whole message. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From dankney@network1.net Mon Mar 19 06:00:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CA721F8656 for ; Mon, 19 Mar 2012 06:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyN3RptdMYcp for ; Mon, 19 Mar 2012 06:00:06 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34021F8643 for ; Mon, 19 Mar 2012 06:00:06 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 1E79A54285E for ; Mon, 19 Mar 2012 09:00:05 -0400 (EDT) Date: Mon, 19 Mar 2012 09:00:05 -0400 (EDT) From: perl-list To: dhcwg@ietf.org Message-ID: <07a7050f-a6f7-4cb0-bb54-abcf70147d46@zimbra.network1.net> In-Reply-To: Content-Type: multipart/alternative; boundary="=_da107b81-15e3-42a7-9aa0-20153664f652" MIME-Version: 1.0 X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:00:07 -0000 --=_da107b81-15e3-42a7-9aa0-20153664f652 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > From: "Simon Hobson" > To: dhcwg@ietf.org > Sent: Friday, March 16, 2012 4:30:52 PM > Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century! > Well sticking to the specific point, there was a LOT of discussion > ... .... > PS - I don't think the title is quite right. This isn't a fight for > one *OR* the other. > -- > Simon Hobson > Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed > author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas stocking fillers. Some available as e-books. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg indeed! +1 on your whole message from me as well! --=_da107b81-15e3-42a7-9aa0-20153664f652 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>From: <= /b>"Simon Hobson" <linux@thehobsons.co.uk>
To: dhcwg@ietf.o= rg
Sent: Friday, March 16, 2012 4:30:52 PM
Subject: Re:= [dhcwg] DUID vs MAC address: the fight of the century!


Well sti= cking to the specific point, there was a LOT of discussion 
... &= lt;snip> ....

PS - I don't think the title is quite right. This= isn't a fight for
one *OR* the other.

--
Simon Hobson
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
a= uthor Gladys Hobson. Novels - poetry - short stories - ideal as
Christma= s stocking fillers. Some available as e-books.
_________________________= ______________________
dhcwg mailing list
dhcwg@ietf.org
https://w= ww.ietf.org/mailman/listinfo/dhcwg

indeed!  +1 on = your whole message from me as well! --=_da107b81-15e3-42a7-9aa0-20153664f652-- From Ted.Lemon@nominum.com Tue Mar 20 10:30:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0411121F86DF for ; Tue, 20 Mar 2012 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlE+X9+tpG2I for ; Tue, 20 Mar 2012 10:30:46 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53121F86AB for ; Tue, 20 Mar 2012 10:30:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT2i+qhOhaksK+Y4JMnirVuBzFKyhgFx/@postini.com; Tue, 20 Mar 2012 10:30:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 808B81B82C9 for ; Tue, 20 Mar 2012 10:30:18 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 77F8B190052 for ; Tue, 20 Mar 2012 10:30:18 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 20 Mar 2012 10:30:18 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: IETF 83 agenda posted, please check! Thread-Index: AQHNBr8eihwgX55JKkiC6AOF+ETKPw== Date: Tue, 20 Mar 2012 17:30:18 +0000 Message-ID: <26468AA8-0EE9-451A-ADFB-2A1493E33E11@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8DB7FD731C51814FB31EAC69E805A75C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] IETF 83 agenda posted, please check! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:30:47 -0000 Please check to make sure your presentation is on it. If you will be pres= enting slides, please send a link to dhc-chairs@ietf.org and say "meeting m= aterials for ietf 83" in the subject line. Please do not send it just to = me or just to John, and please don't be creative with your subject line=97i= t's easier to keep track of materials if everybody uses the same subject li= ne. Please do send the presentations as soon as you have them. Thanks! From Francis.Dupont@fdupont.fr Tue Mar 20 11:23:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4D721F84EF for ; Tue, 20 Mar 2012 11:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoJXU1UJEJjL for ; Tue, 20 Mar 2012 11:23:46 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 1F56F21F84D2 for ; Tue, 20 Mar 2012 11:23:45 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2KINiOF022791 for ; Tue, 20 Mar 2012 19:23:44 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203201823.q2KINiOF022791@givry.fdupont.fr> From: Francis Dupont To: dhcwg@ietf.org Date: Tue, 20 Mar 2012 19:23:43 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [dhcwg] about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 18:23:47 -0000 Two comments about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt from implementation and experiment: - when IMHO it is a good idea to weaken the "sits on the same, IPv6-accessable host with the DHCPv4 client." to the more standard for a relay "sits on the same link than the DHCPv4 client.", this should not be done with control: it is very nice to serve a DHCPv4 client with a CRA running on another box, but it is less nice to get 3 clients colocated with 3 CRAs on the same link duplicating all queries three time (:-). So I propose to recommend a flag which limits the scope of the CRA service. BTW I have no opinion about what should be its default value. - there can be a real issue with the server identifier as it is now possible for a TSV to have in fact no IPv4 address (or no IPv4 address suitable for a server identifier content). Note the server identifier is required (cf RFC 2131) and some clients complain when it is not presented, but I think the deep source of the issue is its double function: "The 'server identifier' field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers." Of course the second doesn't match the IPv6 transport idea, in particular when one wants to see all DHCPv4 being transported over IPv6 for any reason (and I can see many...). Regards Francis.Dupont@fdupont.fr From jari.arkko@piuha.net Wed Mar 21 01:55:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FCD21F8595 for ; Wed, 21 Mar 2012 01:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+OjzwJgC5r0 for ; Wed, 21 Mar 2012 01:55:42 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5227121F8596 for ; Wed, 21 Mar 2012 01:55:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9745C2CC5D; Wed, 21 Mar 2012 10:55:41 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BMVuSXxLEEZ; Wed, 21 Mar 2012 10:55:41 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DC7BE2CC56; Wed, 21 Mar 2012 10:55:40 +0200 (EET) Message-ID: <4F69978C.8010401@piuha.net> Date: Wed, 21 Mar 2012 10:55:40 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: draft-ietf-dhc-dhcpv6-reconfigure-rebind@tools.ietf.org, Dhcwg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-reconfigure-rebind X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 08:55:43 -0000 I have reviewed this draft. (Exceptionally I'm the AD to do this review for DHC WG because Ralph is one of the authors of this draft.) I have found the draft well written and have no concerns about it. I have initiated IETF last call for it. I did have a couple of editorial comments, however: For me, Section 4 would have benefited from a clearer statement of what material from RFC 3315 was still valid. For example, when I read Section 4 and 5, I wondered what options the server was supposed to use as only the latter section talked about options. Looking at RFC 3315 Section 19.1 there's plenty of text about this. Section 7 has nice story about the use of DHCP authentication. I would have preferred to see also a more real-world related explanation of why these attacks are no worse than other attacks on DHCP to begin with. E.g., if you disable nodes with reconfigure, you can disable them with the regular DHCP process as well. ID nits: > == Outdated reference: A later version (-06) exists of > draft-ietf-dhc-secure-dhcpv6-03 > Jari From iesg-secretary@ietf.org Wed Mar 21 08:36:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8906621E8048; Wed, 21 Mar 2012 08:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y20S5o1aFm-7; Wed, 21 Mar 2012 08:36:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF09D21E800E; Wed, 21 Mar 2012 08:36:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120321153635.21348.42833.idtracker@ietfa.amsl.com> Date: Wed, 21 Mar 2012 08:36:35 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Rebind Capability in DHCPv6 Reconfigure Messages) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:36:36 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Rebind Capability in DHCPv6 Reconfigure Messages' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-reconfigure-rebind/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-reconfigure-rebind/ballot/ No IPR declarations have been submitted directly on this I-D. From pengwu.thu@gmail.com Wed Mar 21 19:02:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD6721E8042 for ; Wed, 21 Mar 2012 19:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3m3CmxuFB-F for ; Wed, 21 Mar 2012 19:02:24 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 460C521E8028 for ; Wed, 21 Mar 2012 19:02:24 -0700 (PDT) Received: by dakl33 with SMTP id l33so2499745dak.31 for ; Wed, 21 Mar 2012 19:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RKtIymnjRl0BOu/iqEcPYJ+u8mXkd2lJhhhCCobPyEg=; b=CLbtfPh3wjUJCY+GcY18iVNPc3B7+Rz0qm4BoRSSdDRqKCh2JJatcysjm4LgWCujEM WdOi91fQWilSbuyREbEuFogBlbcu/8S6jArDm2c6vj158PPmVNe4j256Rg9ZcrPAezU+ OpxYcYORyPqV9bovLpzNuy/Lh/D+finRY38vTmHCqHP57vA9FB4FnOWL1/0S27UdrqO5 9OarX0Tg+RnzPhg+8hgcgVpUFDel1cwUd7gR5IkL/uhvXBngfUM38WAyFGsVvr133OUe 6AWBVvLI+u3ypMwvVQfHMMU4VdvexU21kLNQnYf6wel+FDRMz4SR6k+Ot/zcXgPw29S+ h3hQ== MIME-Version: 1.0 Received: by 10.68.234.134 with SMTP id ue6mr16718930pbc.14.1332381744092; Wed, 21 Mar 2012 19:02:24 -0700 (PDT) Received: by 10.68.237.42 with HTTP; Wed, 21 Mar 2012 19:02:24 -0700 (PDT) In-Reply-To: <201203201823.q2KINiOF022791@givry.fdupont.fr> References: <201203201823.q2KINiOF022791@givry.fdupont.fr> Date: Thu, 22 Mar 2012 10:02:24 +0800 Message-ID: From: Peng Wu To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 02:02:25 -0000 Hi Francis, Thank u for raising these comments in the mailinglist. Please see inline. 2012/3/21 Francis Dupont : > Two comments about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt from > implementation and experiment: > > =A0- when IMHO it is a good idea to weaken the "sits on the same, > =A0IPv6-accessable host with the DHCPv4 client." to the more standard > =A0for a relay "sits on the same link than the DHCPv4 client.", > =A0this should not be done with control: it is very nice to serve > =A0a DHCPv4 client with a CRA running on another box, but it is less > =A0nice to get 3 clients colocated with 3 CRAs on the same link > =A0duplicating all queries three time (:-). > =A0So I propose to recommend a flag which limits the scope of > =A0the CRA service. BTW I have no opinion about what should be > =A0its default value. I think the case of CRA locating on the host and on the link is no doubt important.If you see from outside the host, what we do is actually to have the DHCPv4 client to send and receive message in IPv6. It already has the application scenarios of public 4over6, lightweight 4over6 in SOFTWIRE WG. And I agree the case of CRA on the link is reasonable, too, in the case where we cannot update the DHCP code in the client. Now to the issue you raised, I think in the 2nd case, the CRA should be on the same link as the host, and it should have IPv6 access. So it's kind of the gateway in the usual case, and naturally there is only one CRA which serves all the clients. If there do exists multiple CRAs on the same link, what about refering to the standard procedure of multiple relay on the same link, if there is any? > > =A0- there can be a real issue with the server identifier as it is now > =A0possible for a TSV to have in fact no IPv4 address (or no IPv4 > =A0address suitable for a server identifier content). > =A0Note the server identifier is required (cf RFC 2131) and > =A0some clients complain when it is not presented, but I think > =A0the deep source of the issue is its double function: > =A0"The 'server identifier' field is used both to identify a DHCP server > =A0 in a DHCP message and as a destination address from clients to > =A0 servers." Of course the second doesn't match the IPv6 transport > =A0idea, in particular when one wants to see all DHCPv4 being > =A0transported over IPv6 for any reason (and I can see many...). Yes, the second usage doesn't match. About the first usage, what about we fake an IPv4 address and fill in the server id field? We could extract 32 bits from the interface id in the IPv6 address, or hash the 128 bit IPv6 address to for the 32 bits. Is it good enough for server identification? > > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Francis.Dupont@fdupont.fr Thu Mar 22 04:23:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4F521F865A for ; Thu, 22 Mar 2012 04:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxiA+onYsJrK for ; Thu, 22 Mar 2012 04:23:23 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 7638021F8650 for ; Thu, 22 Mar 2012 04:23:23 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2MBNK9P072203; Thu, 22 Mar 2012 12:23:20 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203221123.q2MBNK9P072203@givry.fdupont.fr> From: Francis Dupont To: Peng Wu In-reply-to: Your message of Thu, 22 Mar 2012 10:02:24 +0800. Date: Thu, 22 Mar 2012 12:23:20 +0100 Sender: Francis.Dupont@fdupont.fr Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 11:23:24 -0000 In your previous mail you wrote: > If there do exists multiple CRAs on the same link, what about refering > to the standard procedure of multiple relay on the same link, if there > is any? => all the relays forward to all the configured servers, for responses they are sent to relays so there is no further duplication. > Yes, the second usage doesn't match. About the first usage, what about > we fake an IPv4 address and fill in the server id field? We could > extract 32 bits from the interface id in the IPv6 address, or hash the > 128 bit IPv6 address to for the 32 bits. Is it good enough for server > identification? => it is good but it breaks the second usage so it won't work... Regards Francis.Dupont@fdupont.fr From pengwu.thu@gmail.com Thu Mar 22 07:51:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799AD21F85E3 for ; Thu, 22 Mar 2012 07:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7loFZnYQ+Ku for ; Thu, 22 Mar 2012 07:51:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E910321F85E1 for ; Thu, 22 Mar 2012 07:51:11 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1784122pbb.31 for ; Thu, 22 Mar 2012 07:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YvwpxkVDxxjB8JGLNrTUoZ1quFvDbhKVkfFbHemohck=; b=AP8+ACW9BYF4BMy6sRtxGsaEPDIkk6ERsG+ybskJmN0uLxvGOxtGfeyblIR5ngaWV0 XWZjbKbKsPkUoQvzcXElaLcomZHbmJKMFugBjgMHc+UyjyKbKLGd2t1TsyoR2VUv0RAd Skdc7+ctCY2doIWw5pHRosBqjNXzlFkEr3T5V53IVIWysHCI4ngBbA47qJ/qBgPcaK+i QTIUwhbit+Wz5I5Jl1DYk9hp65Ru9ncBn5Z6YMoGd799DHOcRE7RmMJWG1WP3woi841q unucA5FEy/TCB6UBFJxDOAD8SCVLVpRxZgUr9xLAvenE6vLfquMu34JVIU4TqgwjPbNw OHug== MIME-Version: 1.0 Received: by 10.68.234.134 with SMTP id ue6mr21730656pbc.14.1332427871720; Thu, 22 Mar 2012 07:51:11 -0700 (PDT) Received: by 10.68.237.42 with HTTP; Thu, 22 Mar 2012 07:51:11 -0700 (PDT) In-Reply-To: <201203221123.q2MBNK9P072203@givry.fdupont.fr> References: <201203221123.q2MBNK9P072203@givry.fdupont.fr> Date: Thu, 22 Mar 2012 22:51:11 +0800 Message-ID: From: Peng Wu To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:51:12 -0000 Hi Francis, 2012/3/22 Francis Dupont : > =A0In your previous mail you wrote: > >> =A0If there do exists multiple CRAs on the same link, what about referin= g >> =A0to the standard procedure of multiple relay on the same link, if ther= e >> =A0is any? > > =3D> all the relays forward to all the configured servers, for responses > they are sent to relays so there is no further duplication. So you believe this is especially harmful in the over-IPv6 context? I'm sorry that I'm still a little lost... Could you explain why and how the flag you proposed work? Thanks > >> =A0Yes, the second usage doesn't match. About the first usage, what abou= t >> =A0we fake an IPv4 address and fill in the server id field? We could >> =A0extract 32 bits from the interface id in the IPv6 address, or hash th= e >> =A0128 bit IPv6 address to for the 32 bits. Is it good enough for server >> =A0identification? > > =3D> it is good but it breaks the second usage so it won't work... Sorry, apologize that I misunderstand what you point in the previous mail. Here are some thoughts on this issue, 1)For the case of CRA co-locating with host, this should not be an issue because we'll use IPv6 unicast, no matter what is written in this field. We should state it in the draft. For the case of CRA on the link: 2)Make it mandatory that the client send out DHCP message in broadcast manner in this scenario, or 3)Make the CRA to be the gateway and relay unicast DHCP messages; > > Regards > > Francis.Dupont@fdupont.fr From pengwu.thu@gmail.com Thu Mar 22 08:33:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4054921F84F8 for ; Thu, 22 Mar 2012 08:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBA1DTtEogfD for ; Thu, 22 Mar 2012 08:33:55 -0700 (PDT) Received: from mail-pb0-f66.google.com (mail-pb0-f66.google.com [209.85.160.66]) by ietfa.amsl.com (Postfix) with ESMTP id B5FDF21F84B9 for ; Thu, 22 Mar 2012 08:33:55 -0700 (PDT) Received: by pbcup15 with SMTP id up15so869969pbc.1 for ; Thu, 22 Mar 2012 08:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YrMNkCZi5kEbTcPjyhusVhh6a0qXTLONkoFNcntkoN4=; b=N/rAHCfcoVZcIqbibGCZTdefydoZnVKwjRrBCprapOL1ewrFaojJ4zhAf25qgA/Hfn NEiL8nIOz2KYwc/rCCFsXEwvS3OiPqxbz3l/Bmx2ok/k14/xvPKrfAvJQ7Cw2CVOdV5q 6V5MZw/ITZ7JKdfoE0uarxwhM3/y7cJVXBFAE/3YmuTITkfqr8BmhNOCkKCwF8sDvogr PZtVjH/ST4hwrk+nz25p6ewYBwi3Z6qOXHulSFOmqks/ApIvoTaf0c3JoSngNcJAtod7 mK8wQ+Iua/YpiPZ6Kzwwi+NG72QHWgOi0hECgi/4dwhTI5j9OdkD2WwZq96bsqP2wMvy 7Zgg== MIME-Version: 1.0 Received: by 10.68.201.73 with SMTP id jy9mr21409708pbc.35.1332430435542; Thu, 22 Mar 2012 08:33:55 -0700 (PDT) Received: by 10.68.237.42 with HTTP; Thu, 22 Mar 2012 08:33:55 -0700 (PDT) Date: Thu, 22 Mar 2012 23:33:55 +0800 Message-ID: From: Peng Wu To: dhc WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [dhcwg] =?utf-8?q?Request_for_Review_on_draft-ietf=E2=80=8B-dhc-d?= =?utf-8?b?aGNwduKAizQtb3Zlci1pcHbigIs2LTAx?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:33:56 -0000 Hi WG, I would like to request for more reviews on the DHCPv4 over IPv6 draft, and thank Tomek, Francis and the earlier reviewers for their valuable inputs. This draft describes a mechanism of allocating IPv4 addresses to devices in IPv6 networks, for the usage of providing residual IPv4 service. The draft is motivated from IPv4-over-IPv6 tunneling mechanisms in the Softwire WG. With the development of tunneling mechanisms which require this DHCP feature (e.g., Public 4over6, Lightweight 4over6, SD-NAT), we authors very much hope to improve the draft, move forward it and possibly meet the timeline. We would really appreciate it if you can provide your valuable comments. Here is the link to the draft: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-01 Thanks! ---- Peng Wu From Francis.Dupont@fdupont.fr Mon Mar 26 01:06:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871F121F84D8 for ; Mon, 26 Mar 2012 01:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aNN9sKcpd0m for ; Mon, 26 Mar 2012 01:06:34 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id D66BB21F84D3 for ; Mon, 26 Mar 2012 01:06:33 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2Q86V4w011960; Mon, 26 Mar 2012 10:06:31 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203260806.q2Q86V4w011960@givry.fdupont.fr> From: Francis Dupont To: Peng Wu In-reply-to: Your message of Thu, 22 Mar 2012 22:51:11 +0800. Date: Mon, 26 Mar 2012 10:06:31 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:06:35 -0000 In your previous mail you wrote: > > => all the relays forward to all the configured servers, for responses > > they are sent to relays so there is no further duplication. > So you believe this is especially harmful in the over-IPv6 context? => no and BTW this is what you want when you have many relays to serve the same link, or configure a relay with many server addresses. > I'm sorry that I'm still a little lost... > Could you explain why and how the flag you proposed work? Thanks => as the same code is able to serve the colocated client or the whole link, IMHO a flag is required so the administrator is able to choose between the two available scopes of service. Now about the way to implement it: check if the query comes from the same box or not. > > => it is good but it breaks the second usage so it won't work... > Sorry, apologize that I misunderstand what you point in the previous mail. > Here are some thoughts on this issue, > 1)For the case of CRA co-locating with host, this should not be an > issue because we'll use IPv6 unicast, no matter what is written in > this field. We should state it in the draft. => you miss the point: some clients use the server-identifier to unicast in IPv4 the request to the server (i.e., to the IPv4 / the content of the server-identifier option). So it is no related to the scope of the CRA service. > For the case of CRA on the link: > 2)Make it mandatory that the client send out DHCP message in broadcast > manner in this scenario, or => you can't change the behavior of the DHCPv4 client. > 3)Make the CRA to be the gateway and relay unicast DHCP messages; => it doesn't work: nothing can be the IPv4 gateway for just a given protocol and port. Regards Francis.Dupont@fdupont.fr PS: for anybody who is lost, the issue is the second part of: "The 'server identifier' field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers." when you want to run the whole DHCPv4 protocol exchange(s) over a not IPv4 transport. From Ted.Lemon@nominum.com Mon Mar 26 15:18:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF5B21E802C for ; Mon, 26 Mar 2012 15:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShYCPQPl3tN3 for ; Mon, 26 Mar 2012 15:18:49 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 1A77E21E801F for ; Mon, 26 Mar 2012 15:18:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT3DrSMifgeIPYdgMs3Gniy2DMncpbL4h@postini.com; Mon, 26 Mar 2012 15:18:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2FD471B82B0 for ; Mon, 26 Mar 2012 15:18:48 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 29FD219006B for ; Mon, 26 Mar 2012 15:18:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 26 Mar 2012 15:18:48 -0700 From: Ted Lemon To: "dhcwg@ietf.org" Thread-Topic: Review for draft-ietf-mip6-hiopt-18.txt? Thread-Index: Ac0LnmoYJU1r7wGSSCaRFeDl6AKpBw== Date: Mon, 26 Mar 2012 22:18:47 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472B974C@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Review for draft-ietf-mip6-hiopt-18.txt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 22:18:50 -0000 We've published a new version of the draft-ietf-mip6-hiopt document. This= fixes the problems that were discovered in the document late in the public= ation process. If anybody has time to read it, I would appreciate it if t= hey could do so, although I realize that this is probably a bad time to ask= . http://tools.ietf.org/html/draft-ietf-mip6-hiopt-18 Thanks! From sarikaya2012@gmail.com Tue Mar 27 00:35:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1275121F8724 for ; Tue, 27 Mar 2012 00:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw3zwzm0SprY for ; Tue, 27 Mar 2012 00:35:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3204A21F8711 for ; Tue, 27 Mar 2012 00:35:06 -0700 (PDT) Received: by iazz13 with SMTP id z13so11141566iaz.31 for ; Tue, 27 Mar 2012 00:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=aOMUK63iKtjWx/kJPxUkduluZkt3i92dWZuturj6aQI=; b=D3XwN/+ZneBeXOqlSNIZvmJ/H0bYO1amnqcUDJep1Kl1y0W+c2huSEz5kCgl0aVbRM WVwjnniTEpCw/foYrV1A3AiLmO/6IrzK+O3xdPzEBnWS7Ju5bVB2F44OEoMjknVRUcHJ PK+QqVH5/HpqvwOHW5KUu2F1A9M03/9sw2SU1RrmubIfGY5HwZy1JrsIgmhXmchulaSA UfUyJfZjOrY1K4GA62E13xjyEuRWa84Z65MQRyfrsFBJzfk0Yfz3fJntAw2XYLYwLcPt V4nKQA7gE/Ms71eY/ocvLJ0QO+NBxk9RgUT/7gQPBnyilob9yhgIClY2HzWT2z8x0tke h0HQ== MIME-Version: 1.0 Received: by 10.50.222.131 with SMTP id qm3mr7634780igc.66.1332833703335; Tue, 27 Mar 2012 00:35:03 -0700 (PDT) Received: by 10.231.179.71 with HTTP; Tue, 27 Mar 2012 00:35:03 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472B974C@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307472B974C@mbx-01.win.nominum.com> Date: Tue, 27 Mar 2012 02:35:03 -0500 Message-ID: From: Behcet Sarikaya To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Review for draft-ietf-mip6-hiopt-18.txt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:35:08 -0000 Hi Ted, Thanks for *finally* getting this document through. We had a document that was dependent on this on hiopt IPv4, http://tools.ietf.org/html/draft-xia-mext-hioptv4-04 I would like people to review this one too and hope that the two documents can move forward. Regards, Behcet On Mon, Mar 26, 2012 at 5:18 PM, Ted Lemon wrote: > We've published a new version of the draft-ietf-mip6-hiopt document. =A0 = This fixes the problems that were discovered in the document late in the pu= blication process. =A0 If anybody has time to read it, I would appreciate i= t if they could do so, although I realize that this is probably a bad time = to ask. > > http://tools.ietf.org/html/draft-ietf-mip6-hiopt-18 > > Thanks! > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From alper.yegin@yegin.org Tue Mar 27 08:06:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B48421E822B for ; Tue, 27 Mar 2012 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f36AajcjstMY for ; Tue, 27 Mar 2012 08:06:41 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3808921E81A0 for ; Tue, 27 Mar 2012 08:06:41 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LpsUx-1SiYfq0rBP-00f0QZ; Tue, 27 Mar 2012 11:06:40 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Alper Yegin In-Reply-To: Date: Tue, 27 Mar 2012 18:06:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F208A97-BFF3-4820-BA98-3E47AC41D992@yegin.org> References: To: dhc WG X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:vbMQccG5t+/kaUJp4OsoM2d1tCOxQhkbWZ/+WdXpHe/ sia3eg/hP0P+f4b0bWDrrVMGnMkuAOIrVeUZokgvdj08Sd2xy+ ACWvtfXv+GAvhLVL9wl0D7oUW2/2rjNCad5c26a4YBDyNsyAml 17zIyHlGvT1rQ/IqcRdcaBvo3KdCFXDeerrJX7ZpElb5+qqG1/ pYWBL1RByamCK8IgmA2SFn7ZE4rHxWjjQGVb2TXiWFnPCUBetv wr5UwoSoikTqbV8VMy8xDw05sGO8MIpYxt2ML8e8Nr4iD4UaLy tTwlgOqgLBiDSsDjV8NZ5Q6v+R8i4ouGy1/LmLOVPKfSrEFOl/ 8JeXn5h8fbR45FmPiT0B1fAK1420g74gPAvzawSFw Subject: [dhcwg] draft-bi-dhc-sec-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:06:44 -0000 Not that this draft is the source of this issue , but it certainly = highlights the following: RFC 3118 is not used. Sending security parameters over DHCP needs = consideration. =20= From Ted.Lemon@nominum.com Tue Mar 27 08:19:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7AF21F8907 for ; Tue, 27 Mar 2012 08:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJJZCLidUgCJ for ; Tue, 27 Mar 2012 08:19:59 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id DE69521F8902 for ; Tue, 27 Mar 2012 08:19:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT3HanqW1ya3yg7GMI2aqlBDsYDb0AWpU@postini.com; Tue, 27 Mar 2012 08:19:58 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 97EB51B813F for ; Tue, 27 Mar 2012 08:19:57 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 89EF7190068; Tue, 27 Mar 2012 08:19:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 08:19:57 -0700 From: Ted Lemon To: Alper Yegin , dhc WG Thread-Topic: [dhcwg] draft-bi-dhc-sec-option Thread-Index: AQHNDCs97FdY0hE8ekCzaZlLGDHV+ZZ+QWZI Date: Tue, 27 Mar 2012 15:19:57 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C3E6F@mbx-02.win.nominum.com> References: , <2F208A97-BFF3-4820-BA98-3E47AC41D992@yegin.org> In-Reply-To: <2F208A97-BFF3-4820-BA98-3E47AC41D992@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] draft-bi-dhc-sec-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:19:59 -0000 > RFC 3118 is not used. Sending security parameters over DHCP needs conside= ration. Yes, we have pretty much given up on providing information like this in DHC= P. It doesn't make any sense to do so, because DHCP does not operate in c= ontrolled administrative domains. Even if you authenticate the DHCP serve= r, you still can't trust it to tell you what PKI server to talk to. From Ted.Lemon@nominum.com Wed Mar 28 03:49:03 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2090821F8A48 for ; Wed, 28 Mar 2012 03:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2TIAxt1OzCr for ; Wed, 28 Mar 2012 03:49:00 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9A721F8A4B for ; Wed, 28 Mar 2012 03:48:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Lsm+JNy57bCJ0onwkt0JLLHb5eqXUX@postini.com; Wed, 28 Mar 2012 03:49:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EC9A41B80CC for ; Wed, 28 Mar 2012 03:48:58 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DE01A190064; Wed, 28 Mar 2012 03:48:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 28 Mar 2012 03:48:59 -0700 From: Ted Lemon To: Leaf yeh , dhc WG Thread-Topic: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt Thread-Index: AQHM+rJ5wB5yedLmdUWX9jy95pvuKZZc55HwgCLDgtA= Date: Wed, 28 Mar 2012 10:48:57 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D0C15@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/mixed; boundary="_002_8D23D4052ABE7A4490E77B1A012B6307472D0C15mbx01winnominum_" MIME-Version: 1.0 Subject: Re: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:49:03 -0000 --_002_8D23D4052ABE7A4490E77B1A012B6307472D0C15mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had a chance to give the draft a thorough read yesterday; I've attached c= omments and proposed edits. --_002_8D23D4052ABE7A4490E77B1A012B6307472D0C15mbx01winnominum_ Content-Type: text/plain; name="draft-yeh-dhc-dhcpv6-authorization-opt-00.txt" Content-Description: draft-yeh-dhc-dhcpv6-authorization-opt-00.txt Content-Disposition: attachment; filename="draft-yeh-dhc-dhcpv6-authorization-opt-00.txt"; size=24045; creation-date="Wed, 28 Mar 2012 10:48:40 GMT"; modification-date="Wed, 28 Mar 2012 10:48:40 GMT" Content-Transfer-Encoding: base64 CgoKREhDIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEwuIFllaCwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSHVhd2VpIFRlY2hub2xvZ2llcwpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDUsIDIwMTIKRXhwaXJl czogU2VwdGVtYmVyIDYsIDIwMTIKCgpBdXRob3JpemF0aW9uIE9wdGlvbiBmb3IgREhDUHY2IFJl bGF5IEFnZW50cyBvbiBCcm9hZGJhbmQgQWNjZXNzIFNlcnZlcgogICAgICAgICAgICAgICBkcmFm dC15ZWgtZGhjLWRoY3B2Ni1hdXRob3JpemF0aW9uLW9wdC0wMAoKQWJzdHJhY3QKCiAgIFRoZSBE SENQdjYgYXV0aG9yaXphdGlvbiBvcHRpb24gcHJvdmlkZXMgYSBjb21tdW5pY2F0aW9uIG1lY2hh bmlzbQogICBiZXR3ZWVuIHJlbGF5IGFnZW50IGFuZCB0aGUgc2VydmVyLiAgVGhpcyBtZWNoYW5p c20gY2FuIGhlbHAgdGhlCiAgIGNlbnRyYWxpemVkIERIQ1B2NiBzZXJ2ZXIgdG8gc2VsZWN0IHRo ZSByaWdodCBjb25maWd1cmF0aW9uIGZvciB0aGUKICAgY2xpZW50IGJhc2VkIG9uIHRoZSBhdXRo b3JpemF0aW9uIGluZm9ybWF0aW9uIGdvdCBmcm9tIHRoZQpzL2dvdC9yZWNlaXZlZC8KICAgY2Vu dHJhbGl6ZWQgUkFESVVTIHNlcnZlciB3aGljaCBpcyBub3QgbG9jYXRlZCBhdCB0aGUgc2FtZSBw bGFjZSBvZgogICBESENQdjYgc2VydmVyIGluIHRoZSBjYXNlIHdoZW4gdGhlIE5BUyB3b3JrcyBh cyBESENQdjYgcmVsYXkgYWdlbnQKICAgYW5kIFJBRElVUyBjbGllbnQgc2ltdWx0YW5lb3VzbHku CnMvdGhlIGNlbnRyYWxpemVkIFJBRElVUyBzZXJ2ZXIgd2hpY2ggaXMgbm90IGxvY2F0ZWQgYXQg dGhlIHNhbWUgcGxhY2Ugb2YgREhDUHY2IHNlcnZlci8KIC9hIHNlcGFyYXRlIFJBRElVUyBzZXJ2 ZXIvCnMvaW4gdGhlIGNhc2Ugd2hlbiB0aGUgTkFTIHdvcmtzL2luIGNhc2VzIHdoZXJlIHRoZSBO QVMgYWN0cy8KCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlz IHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2Yg QkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5v dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQog ICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50 Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1h eGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHBy b3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBv ciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlz IEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHRlbWJlciA2LCAyMDEyLgoKQ29weXJp Z2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJz b25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJl c2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElF VEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRz CiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0 aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmll dyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmln aHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1 ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQu ZSBvZgoKCgpZZWggICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA2LCAyMDEy ICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIERIQ1B2NiBB dXRob3JpemF0aW9uIE9wdGlvbiAgICAgICAgICAgIE1hcmNoIDIwMTIKCgogICB0aGUgVHJ1c3Qg TGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAg ZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKClRhYmxlIG9mIENvbnRl bnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgMi4gIFRlcm1pbm9sb2d5IGFuZCBMYW5ndWFnZSAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAgIDMuICBOZXR3b3JrIFNjZW5h cmlvICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNAogICA0 LiAgT3B0aW9uX0F1dGhvcml6YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDUKICAgNS4gIFN1Yi1vcHRpb25zIG9mIE9wdGlvbl9BdXRob3JpemF0aW9uIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgICAgNS4xLiAgT3B0aW9uX1Bvb2xfTmFtZSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNgogICAgIDUuMi4gIE9w dGlvbl9BZGRyZXNzX1ByZWZpeF9BdXRoICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDYKICAgNi4gIFJlbGF5IEFnZW50IEJlaGF2aW9yICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA3CiAgIDcuICBTZXJ2ZXIgQmVoYXZpb3IgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICA4LiAgQ2xpZW50IEJlaGF2aW9y IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgKICAgOS4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA4CiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOAogICAxMS4gQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgKICAgMTIuIFJlZmVyZW5j ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA4 CiAgICAgMTIuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gOAogICAgIDEyLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDkKICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA5CgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgpZZWggICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRl bWJlciA2LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgIERIQ1B2NiBBdXRob3JpemF0aW9uIE9wdGlvbiAgICAgICAgICAgIE1hcmNoIDIwMTIKCgox LiAgSW50cm9kdWN0aW9uCgogICBESENQdjYgaGFzIGJlZW4gZGVzaWduZWQgZm9yIHRoZSBzZXJ2 ZXIgdG8gcHJvdmlkZSwgYXNzaWduIG9yCiAgIGRlbGVnYXRlIGJvdGggc3RhdGVmdWwgYW5kIHN0 YXRlbGVzcyBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgdG8gdGhlCnMvaGFzIGJlZW4gZGVzaWdu ZWQgZm9yIHRoZSBzZXJ2ZXIgdG8vcHJvdmlkZXMgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdGhl IHNlcnZlciB0by8KICAgY2xpZW50cy4gIFRoZSBzdGF0ZWZ1bCBjb25maWd1cmF0aW9uIHBhcmFt ZXRlcnMgaW5jbHVkZSBJUHY2IGFkZHJlc3MKcy90byB0aGUgY2xpZW50cy90byBjbGllbnRzLwog ICBbUkZDMzMxNV0sIElQdjYgcHJlZml4IFtSRkMzNjMzXSwgYW5kIGV0Yy4gIFRoZSBzdGF0ZWxl c3MKICAgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIGluY2x1ZGUgRE5TIFtSRkMzNjQ2XSwgYW5k IGV0YyBbUkZDMzczNl0uCnMvVGhlIHN0YXRlbGVzcyBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMg aW5jbHVkZSBETlMgW1JGQzM2NDZdLCBhbmQgZXRjIFtSRkMzNzM2XS4vCiAvU3RhdGVsZXNzIGNv bmZpZ3VyYXRpb24gcGFyYW1ldGVycyBbUkZDMzczNl0gaW5jbHVkZSwgZm9yIGV4YW1wbGUsIERO UyBbUkZDMzY0Nl0uLwogICBUaGUgc2VydmVyIGNvdWxkIGFsd2F5cyBiZSBkZXBsb3llZCBhcyBh IGNlbnRyYWxpemVkIG9uZSBpbiB0aGUgSVNQCiAgIG5ldHdvcmsuCnMvVGhlIHNlcnZlciBjb3Vs ZCBhbHdheXMgYmUgZGVwbG95ZWQgYXMgYSBjZW50cmFsaXplZCBvbmUvCiAvREhDUCBzZXJ2ZXJz IGFyZSB0eXBpY2FsbHkgZGVwbG95ZWQgaW4gYSBjZW50cmFsIHBhcnQgb2YgYW4gSVNQIG5ldHdv cmsuLwoKICAgRXNzZW50aWFsbHkgYXMgYSBzdGF0ZWxlc3MgcHJvdG9jb2wsIFJBRElVUyBbUkZD Mjg2NV0gaGFzIGJlZW4gd2lkZWx5CiAgIHVzZWQgYXMgdGhlIGNlbnRyYWxpemVkIGF1dGhlbnRp Y2F0aW9uLCBhdXRob3JpemF0aW9uIGFuZCB1c2VyCnMvRXNzZW50aWFsbHkgYXMgYSBzdGF0ZWxl c3MgcHJvdG9jb2wsIFJBRElVUyBbUkZDMjg2NV0gaGFzIGJlZW4gd2lkZWx5IHVzZWQvCiAvUkFE SVVTLCBhbiBlc3NlbnRpYWxseSBzdGF0ZWxlc3MgcHJvdG9jb2wsIGlzIGluIHdpZGUgdXNlLwog ICBtYW5hZ2VtZW50IG1ldGhvZCBmb3IgdGhlIHNlcnZpY2UgcHJvdmlzaW9uIGluIEJyb2FkYmFu ZCBhY2Nlc3MKcy9tZXRob2QvbWVjaGFuaXNtLwogICBuZXR3b3JrLiAgW1JGQzMxNjJdLCBbUkZD NDgxOF0gYW5kIFtpZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNl0gaGFzCiAgIHNwZWNpZmllZCBz b21lIGF0dHJpYnV0ZXMgdG8gc3VwcG9ydCB0aGUgc2VydmljZSBwcm92aXNpb24gZm9yIElQdjYK cy9oYXMgc3BlY2lmaWVkIHNvbWUgYXR0cmlidXRlcyB0by9zcGVjaWZ5IGF0dHJpYnV0ZXMgdGhh dC8Kcy90aGUgc2VydmljZSBwcm92aXNpb24vdGhlIHByb3Zpc2lvbiBvZiBzZXJ2aWNlLwogICBh Y2Nlc3MsIHdoaWNoIGF1dGhvcml6ZSBOQVMgdG8gYXNzaWduIElQdjYgYWRkcmVzcyBvciBwcmVm aXggZnJvbSB0aGUKcy8sIHdoaWNoIGF1dGhvcml6ZS8uICBSQURJVVMgYXV0aG9yaXplcyB0aGUv CnMvYXNzaWduIGFkZHJlc3Mgb3IgcHJlZml4L2Fzc2lnbnMgYW4gYWRkcmVzcyBvciBwcmVmaXgv CiAgIGluZGljYXRlZCBwb29sLCBvciBhc3NpZ24gSVB2NiBhZGRyZXNzIG9yIHByZWZpeCB3aXRo IHRoZSBleHBsaWNpdGx5CnMvYXNzaWduIGFkZHJlc3Mgb3IgcHJlZml4L2Fzc2lnbnMgYW4gYWRk cmVzcyBvciBwcmVmaXgvCnMvdGhlIGV4cGxpY2l0bHkvYW4gZXhwbGljaXRseS8KICAgaW5kaWNh dGVkIHZhbHVlLCBmb3IgdGhlIHVzZXJzIHdoaWNoIGFsc28gYWN0cyBhcyBhIERIQ1B2NiBjbGll bnQuCnMvLCBmb3IgdGhlIHVzZXJzIHdoaWNoIGFsc28gYWN0cyBhcyBhIERIQ1AgY2xpZW50Li8K IC9YWFgvIChJIGRvbid0IGtub3cgd2hhdCB5b3UgbWVhbiBoZXJlLikKCiAgIFRoZXNlIG1lY2hh bmlzbSBjYW4gd29yayBmaW5lIHdpdGggdGhlIGRlcGxveW1lbnQgc2NlbmFyaW9zIHdoZW4gTkFT CnMvIiIvVGhpcyBtZWNoYW5pc20gd29ya3Mgd2VsbCBpbiBkZXBsb3ltZW50IHNjZW5hcmlvcyB3 aGVyZSB0aGUgTkFTLwogICBhY3RzIGFzIHRoZSBkaXN0cmlidXRlZCBESENQdjYgc2VydmVyLCBO QVMgY2FuIGV4ZWN1dGUgdGhlIGluZGljYXRpb24KICAgc2hvd24gaW4gdGhlIGF0dHJpYnV0ZXMg b2YgdGhlIEFjY2Vzcy1BY2NlcHQgbWVzc2FnZSBvZiBSQURJVVMuICBJdApzLywgTkFTIGNhbiBl eGVjdXRlIHRoZSBpbmRpY2F0aW9uIHNob3duLy4gIEluIHRoaXMgY2FzZSB0aGUgTkFTIHJlc3Bv bmRzIGFzIGluZGljYXRlZCBieSB0aGUgUkFESVVTIHNlcnZlci4vIAogICBhbHNvIG1pZ2h0IGJl IGZpbmUgd2l0aCB0aGUgbmV0d29yayBhcmNoaXRlY3R1cmUgd2hlbiB0aGUgY2VudHJhbGl6ZWQK ICAgREhDUHY2IHNlcnZlciBsb2NhdGVzIGluIHRoZSBzYW1lIHBsYWNlIHdpdGggdGhlIFJBRElV UyBzZXJ2ZXIsIHdoZXJlCnMvSXQgYWxzbyBtaWdodCBiZSBmaW5lIHdpdGggdGhlIG5ldHdvcmsg YXJjaGl0ZWN0dXJlIHdoZW4gdGhlIGNlbnRyYWxpemVkIERIQ1Agc2VydmVyIGxvY2F0ZXMvCiAv VGhpcyBhbHNvIHdvcmtzIGluIHRoZSBzY2VuYXJpbyB3aGVyZSB0aGUgREhDUCBzZXJ2ZXIgaXMg bG9jYXRlZC8KICAgdGhleSBjb3VsZCBzaGFyZSB0aGUgc2FtZSBkYXRhYmFzZSBvZiB0aGUgdXNl cnMuICBCdXQgd2hlbiBOQVMgYWN0cwpzLywgd2hlcmUgdGhleSBjb3VsZCBzaGFyZSB0aGUgc2Ft ZSBkYXRhYmFzZSBvZiB0aGUgdXNlcnMvCiAvOiB0aGV5IGNhbiBzaGFyZSB0aGUgc2FtZSBkYXRh YmFzZSBvZiB1c2Vycy8KICAgYXMgdGhlIHJlbGF5IGFnZW50IGFuZCBSQURJVVMgY2xpZW50IHNp bXVsdGFuZW91c2x5LCBhbmQgdGhlCiAgIGNlbnRyYWxpemVkIERIQ1B2NiBzZXJ2ZXIgaXMgbm90 IGxvY2F0ZWQgaW4gdGhlIHNhbWUgcGxhY2Ugd2l0aAogICBSQURJVVMgc2VydmVyLCBhIG5ldyBj b21tdW5pY2F0aW9uIG1lY2hhbmlzbSBpcyBuZWVkIGZvciB0aGUgcmVsYXkKcy93aXRoIFJBRElV Uy9hcyB0aGUgUkFESVVTLwpzL2lzIG5lZWQvaXMgbmVlZGVkLwogICBhZ2VudCB0byB0cmFuc2Zl ciB0aGUgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiBnb3QgZnJvbSB0aGUgUkFESVVTCnMvZ290 IGZyb20vaW5kaWNhdGVkIGJ5LwogICBhdHRyaWJ1dGVzIHRvIHRoZSBESENQdjYgc2VydmVyLgpz L3RvIHRoZSBESENQdjYgc2VydmVyLy8KCgoyLiAgVGVybWlub2xvZ3kgYW5kIExhbmd1YWdlCgog ICBUaGlzIGRvY3VtZW50IHNwZWNpZmllZCBhIERIQ1B2NiBvcHRpb24gZm9yIFJlbGF5IEFnZW50 IHRvIHByb3ZpZGUKcy9zcGVjaWZpZWQvc3BlY2lmaWVzLwogICB0aGUgaW5mb3JtYXRpb24gZ290 IGZyb20gUkFESVVTIGF0dHJpYnV0ZXMgdG8gdGhlIERIQ1B2NiBzZXJ2ZXIuCnMvdGhlIGluZm9y bWF0aW9uIGdvdCBmcm9tIFJBRElVUyBhdHRyaWJ1dGVzL2luZm9ybWF0aW9uIGZyb20gc29tZSBS QURJVVMgYXR0cmlidXRlcy8KICAgVGhpcyBkb2N1bWVudCBzaG91bGQgYmUgcmVhZCBpbiBjb25q dW5jdGlvbiB3aXRoIHRoZSBmb2xsb3dpbmcKICAgc3BlY2lmaWNhdGlvbnMsIFtSRkMyODY1XSwg W1JGQzI4NjldLCBbUkZDMzMxNV0gYW5kIFtSRkM0ODE4XSBmb3IKICAgdW5kZXJzdGFuZGluZyB0 aGUgY29tcGxldGUgbWVjaGFuaXNtIG9mIERIQ1B2NiBhbmQgUkFESVVTIHdpdGggdGhlCnMvZm9y IHVuZGVyc3RhbmRpbmcvLiAgVGhlc2Ugd2lsbCBoZWxwIHRoZSByZWFkZXIgdG8gdW5kZXJzdGFu ZC8KICAgc2VydmljZSBwcm92aXNpb24gb2YgSVB2Ni4gIERlZmluaXRpb25zIGZvciB0ZXJtcyBh bmQgYWNyb255bXMgbm90CnMvdGhlIGNvbXBsZXRlIG1lY2hhbmlzbSBvZi9ob3cvCnMvd2l0aCB0 aGUgc2VydmljZSBwcm92aXNpb24vd29yayB0b2dldGhlciB0byBwcm92aWRlIElQdjYgc2Vydmlj ZS8KICAgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIGRlZmluZWQgaW4gW1JGQzI4NjVd LCBbUkZDMjg2OV0sCiAgIFtSRkMzMzE1XSBhbmQgW1JGQzQ4MThdLgoKICAgVGhlIGtleXdvcmRz IE1VU1QsIE1VU1QgTk9ULCBSRVFVSVJFRCwgU0hBTEwsIFNIQUxMIE5PVCwgU0hPVUxELAogICBT SE9VTEQgTk9ULCBSRUNPTU1FTkRFRCwgTUFZLCBhbmQgT1BUSU9OQUwsIHdoZW4gdGhleSBhcHBl YXIgaW4gdGhpcwogICBkb2N1bWVudCwgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJl ZCBpbiBCQ1AgMTQsIFtSRkMyMTE5XS4KCgoKCgpZZWggICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIFNlcHRlbWJlciA2LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgIERIQ1B2NiBBdXRob3JpemF0aW9uIE9wdGlvbiAgICAgICAgICAgIE1hcmNo IDIwMTIKCgozLiAgTmV0d29yayBTY2VuYXJpbwoKICAgRmlndXJlIDEgc2hvd3MgdGhlIHR5cGlj YWwgbmV0d29yayBzY2VuYXJpbyB3aGVyZSB0byBhZG9wdCB0aGUKcy93aGVyZSB0byBhZG9wdC93 aGVyZS8KICAgY29tbXVuaWNhdGlvbiBtZWNoYW5pc20gaW50cm9kdWNlZCBpbiB0aGlzIGRvY3Vt ZW50LiAgSW4gdGhpcwpzL2RvY3VtZW50L2RvY3VtZW50IGlzIG5lY2Vzc2FyeS4vCiAgIFNjZW5h cmlvLCB0aGUgY2VudHJhbGl6ZWQgREhDUHY2IHNlcnZlciBpcyBub3QgbG9jYXRlZCBpbiB0aGUg c2FtZQpzL1NjZW5hcmlvL3NjZW5hcmlvLwogICBwbGFjZSB3aXRoIFJBRElVUyBzZXJ2ZXIgYnV0 IGluIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGRvbWFpbjsgYW5kCnMvYnV0IGluL2J1dCBpcyBp bi8Kcy87IGFuZC8uIFRoZS8KICAgTkFTIGFjdHMgYXMgdGhlIHJlbGF5IGFnZW50IGFuZCBSQURJ VVMgY2xpZW50IHNpbXVsdGFuZW91c2x5LiAgT24gdGhlCnMvYWN0cyBhcy9hY3RzIGJvdGggYXMv CnMvUkFESVVTL3RoZSBSQURJVVMvCnMvc2ltdWx0YW5lb3VzbHkvLwogICBvdGhlciBoYW5kLCBG aWd1cmUgMSBhbHNvIHNob3dzIHRoZSBtZXNzYWdlIHNlcXVlbmNlIG9mIERIQ1B2NiBhbmQKcy9P biB0aGUgb3RoZXIgaGFuZCwgRmlndXJlIG9uZSBhbHNvL0ZpZ3VyZSBvbmUvCnMvbWVzc2FnZSBz ZXF1ZW5jZS9zZXF1ZW5jZS8KICAgUkFESVVTIG1lc3NhZ2VzIHdoZW4gdG8gZW1wbG95IHRoZSBj b21tdW5pY2F0aW9uIG1lY2hhbmlzbSBpbnRyb2R1Y2VkCiAgIGluIHRoaXMgZG9jdW1lbnQuCnMv d2hlbiB0byBlbXBsb3kvdGhhdCBtdXN0IG9jY3VyIHdoZW4gZW1wbG95aW5nLwoKICAgKy0tLS0t LS0rICAgICAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0rCiAgIHxESENQdjYgfCAgIEFjY2VzcyBNb2RlOiAgICB8ICBOQVMgIHwgICAgICAgICAgICAg ICAgICAgIHxSYWRpdXMgfAogICB8Q2xpZW50IHwgICBQUFBvRSBvciBJUG9FICAgfChESENQdjZ8 ICAgICAgICAgICAgICAgICAgICB8U2VydmVyIHwKICAgfCAgICAgICB8ICAgICAgICAgICAgICAg ICAgIHwgUmVsYXkpfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiAgICstLS0tLS0tKyAg ICAgICAgICAgICAgICAgICArLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICstLS0tLS0tKwog ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgfC0tLVNvbGljaXQtLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS1B Y2Nlc3MtUmVxdWVzdC0tLS0tLS0tLS0+fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHw8LS1BY2Nlc3MtQWNjZXB0LS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAoZS5nLiBGcmFtZWQtUG9vbCkKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgKGUuZy4gRGVsZWdhdGVkLUlQdjYtUHJlZml4KQoKICAgICAgICAg ICAgICBESENQdjYgbWVzc2FnZXMgICAgICAgICAgICAgUkFESVVTIG1lc3NhZ2VzCgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgfERIQ1B2NiB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgIHxTZXJ2ZXIgfAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0r CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLVJlbGF5LUZvcndhcmQtLS0t LS0tLS0tLT58CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIChPcHRpb25f QXV0aG9yaXphdGlvbikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tUmVs YXktUmVwbHkgLS0tLS0tLS0tLS0tLXwKICAgICAgIHw8LS1BZHZlcnRpc2UtLS0tLS0tLS0tLS0t LS18CiAgICAgICAgICAgKGUuZy4gUHJlZml4LCBBZGRyZXNzKSAgfAogICAgICAgfC0tLVJlcXVl c3QtLS0tLS0tLS0tLS0tLS0tPnwKICAgICAgICAgICAoZS5nLiBQcmVmaXgsIEFkZHJlc3MpICB8 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLVJlbGF5LUZvcndhcmQtLS0t LS0tLS0tLT58CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIChPcHRpb25f QXV0aG9yaXphdGlvbikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tUmVs YXktUmVwbHkgLS0tLS0tLS0tLS0tLXwKICAgICAgIHw8LS1SZXBseS0tLS0tLS0tLS0tLS0tLS0t LS18CiAgICAgICAgICAgKGUuZy4gUHJlZml4LCBBZGRyZXNzKSAgfAoKICAgICAgICAgICAgICBE SENQdjYgbWVzc2FnZXMgICAgICAgICAgICAgREhDUHY2IG1lc3NhZ2VzCgogICAgICBGaWd1cmUg MTogTmV0d29yayBTY2VuYXJpbyBhbmQgbWVzc2FnZSBzZXF1ZW5jZSB3aGVuIGVtcGxveWluZwog ICAgICAgICAgICAgICAgICAgICAgQXV0aG9yaXphdGlvbiBvcHRpb24gb2YgREhDUHY2CgoKCgpZ ZWggICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA2LCAyMDEyICAgICAgICAg ICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIERIQ1B2NiBBdXRob3JpemF0 aW9uIE9wdGlvbiAgICAgICAgICAgIE1hcmNoIDIwMTIKCgo0LiAgT3B0aW9uX0F1dGhvcml6YXRp b24KCiAgIFRoZSBPcHRpb25fQXV0aG9yaXphdGlvbiBpcyBhIHN0YXRlbGVzcyBESENQdjYgb3B0 aW9uLCB3aGljaCBpcyB1c2VkCiAgIHRvIGNhcnJ5IHRoZSBpbmZvcm1hdGlvbiBnb3QgZnJvbSB0 aGUgUkFERElVUyBhdHRyaWJ1dGVzLiAgVGhvc2UKICAgUkFESVVTIGF0dHJpYnV0ZXMgbWF5IGlu Y2x1ZGUgYnV0IG5vdCBvbmx5IEZyYW1lZC1Qb29sICg4OCkgZGVmaW5lZAogICBpbiBbUkZDMjg2 OV0sIERlbGVnYXRlZC1JUHY2LVByZWZpeCAoMTIzKSBkZWZpbmVkIGluIFtSRkM0ODE4XSwKICAg RnJhbWVkLUlQdjYtQWRkcmVzcywgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wsIERlbGVnYXRl ZC1JUHY2LQogICBQcmVmaXgtUG9vbCBkZWZpbmVkIGluIFtpZXRmLXJhZGV4dC1pcHY2LWFjY2Vz cy0wNl0sIGFuZCBldGMuCgogICBUaGUgZm9ybWF0IG9mIHRoZSBPcHRpb25fQXV0aG9yaXphdGlv biBpcyBkZWZpbmVkIGFzIGZvbGxvd3M6CgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgIHwgICAgIE9wdGlvbl9BdXRob3JpemF0aW9uICAgICAgfCAgICAgICAgIG9wdGlvbi1sZW5n dGggICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICBBdXRob3JpemF0aW9uLW9wdGlv bnMgb3IgUkFESVVTIEF0dHJpYnV0ZXMuLi4KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgIG9wdGlvbi1jb2RlICAg ICAgT3B0aW9uX0F1dGhvcml6YXRpb24gKFRCRCkKICAgb3B0aW9uLWxlbmd0aCAgICBMZW5ndGgg b2YgdGhlIG9wdGlvbi1kYXRhIGluIE9jdGV0cwogICBvcHRpb24tZGF0YSAgICAgIHN1Yi1vcHRp b25zIGFzc29jaWF0ZWQgd2l0aCBPcHRpb25fQXV0aG9yaXphdGlvbgoKICAgRGlzY3Vzc2lvbjog VGhlIG9wdGlvbi1kYXRhIG9mIE9wdGlvbl9BdXRob3JpemF0aW9uIG1heSBoYXZlIDIga2luZHMK ICAgb2YgYWx0ZXJuYXRpdmUgcHJlc2VudGF0aW9uOiBvbmUgaXMgdG8gZGVmaW5lIHRoZSBhc3Nv Y2lhdGVkCiAgIHN0YXRlbGVzcyBzdWItb3B0aW9uIGFzIHVzdWFsIGluIHRoZSBjb250YWluZXIg b3B0aW9uOyB0aGUgb3RoZXIgaXMKICAgdG8gYWRvcHQgdGhlIHNhbWUgbWV0aG9kIG9mIFtSRkM0 MDE0XSwgd2hpY2ggZGlyZWN0bHkgaW5jbHVkZXMgdGhlCiAgIFJBRElVUyBhdHRyaWJ1dGVzIGlu dG8gdGhlIG9wdGlvbi1kYXRhIG9mIE9wdGlvbl9BdXRob3JpemF0aW9uLgoKICAgRGVzaWduLTE6 IFN1Yi1vcHRpb24gYXMgb3B0aW9uLWRhdGEgb2YgT3B0aW9uX0F1dGhvcml6YXRpb24KCiAgICAg IFByb3M6IDEuIGRlZmluZSB0aGUgbmV3IHN1Yi1vcHRpb24gdG8gbWVldCB0aGUgbmV3IHJlcXVp cmVtZW50IGFzCiAgICAgIHVzdWFsLCBuZXcgcmVxdWlyZW1lbnQgdG9kYXkgaXMgbGltaXRlZCBm b3IgdGhlIGFkZHJlc3MgJiBwcmVmaXgKICAgICAgYXNzaWdubWVudDsgMi4gbWlnaHQgaGF2ZSBz b21lIGtpbmQgb2YgbGliZXJ0eSwgbm8gbXVjaCBkZXBlbmRlbmNlCiAgICAgIG9uIHRoZSBkZXZl bG9wbWVudCBwcm9ncmVzcyBvZiBSQURJVVMsIHRvIGRldmVsb3AgaXRzIG93biBvcHRpb24KICAg ICAgd2l0aGluIHRoZSBESENQdjYgcHJvdG9jb2w7CgogICAgICBDb25zOiBidXQgbmVlZCBuZXcg cGFyc2VyIGZvciBlYWNoIG5ldyBvcHRpb24uCgogICBTZWN0aW9uIDUgYWRvcHRzIERlc2lnbi0x LgoKICAgRGVzaWduLTI6IFJBRElVUyBhdHRyaWJ1dGVzIGFzIG9wdGlvbi1kYXRhIG9mIE9wdGlv bl9BdXRob3JpemF0aW9uCgogICAgICBQcm9zOiByZXVzZSB0aGUgcGFyc2VyIGNvZGVzIG9mIFJB RElVUyBhdHRyaWJ1dGVzOwoKICAgICAgQ29uczogYnV0IG5lZWQgREhDUHY2IHNlcnZlciB0byBz dXBwb3J0IHRoZSBwYXJzZXIgY29kZXMgb2YgUkFESVVTCiAgICAgIGZvciBhIGxpc3Qgb2YgYXR0 cmlidXRlcyBhc3NvY2lhdGVkIHdpdGggREhDUHY2LgoKCgoKWWVoICAgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgNiwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICBESENQdjYgQXV0aG9yaXphdGlvbiBPcHRpb24gICAgICAgICAg ICBNYXJjaCAyMDEyCgoKICAgRGVzaWduLTIgaXMgZm9yIHRoZSBmdXJ0aGVyIGRpc2N1c3Npb24u CioqKiBUaGVyZSBpcyBubyByZWFzb24gdG8gdXNlIGVpdGhlciBzdWJvcHRpb25zIG9yIFJBRElV UyBvcHRpb25zLiAgIFRoZQpyaWdodCB0aGluZyB0byBkbyBpcyBzaW1wbHkgZGVmaW5lIGEgREhD UCBvcHRpb24gdG8gY2FycnkgZWFjaCBSQURJVVMgYXR0cmlidXRlCnRoYXQgeW91IHRoaW5rIHRo ZSBESENQIHNlcnZlciBtaWdodCBuZWVkLiAgIFN1Yi1vcHRpb25zIGFyZSBjb21tb24gaW4gREhD UHY0CmJlY2F1c2UgdGhlcmUgYXJlIG9ubHkgMjU2IG9wdGlvbiBjb2RlcyBwb3NzaWJsZSwgYnV0 IGluIERIQ1B2NiB0aGlzIGlzIG5vdCBhCnByb2JsZW0sIGFuZCB0aGUgYWRkaXRpb25hbCBjb21w bGV4aXR5IGludHJvZHVjZWQgYnkgc3Vib3B0aW9ucyBpcyB1bmRlc2lyYWJsZS4KCgo1LiAgU3Vi LW9wdGlvbnMgb2YgT3B0aW9uX0F1dGhvcml6YXRpb24KCioqKiBTbywgdGhlIGZvbGxvd2luZyBz aG91bGQgYWxsIGp1c3QgYmUgREhDUHY2IG9wdGlvbnMsIGFuZCB0aGVyZSBzaG91bGQgYmUKbm8g T3B0aW9uX0F1dGhvcml6YXRpb24gb3B0aW9uLgoKNS4xLiAgT3B0aW9uX1Bvb2xfTmFtZQoKICAg VGhlIE9wdGlvbl9Qb29sX05hbWUgaXMgdXNlZCB0byBjYXJyeSB0aGUgbmFtZSBvZiBJUHY2IGFk ZHJlc3Mgb3IKICAgcHJlZml4IHBvb2wgZ290IGZyb20gdGhlIFJBRElVUyBhdHRyaWJ1dGVzLCBp bmNsdWRpbmcgRnJhbWVkLVBvb2wKICAgKDg4KSBkZWZpbmVkIGluIFtSRkMyODY5XSwgU3RhdGVm dWwtSVB2Ni1BZGRyZXNzLVBvb2wsIERlbGVnYXRlZC0KICAgSVB2Ni1QcmVmaXgtUG9vbCBkZWZp bmVkIGluIFtpZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNl0sIGZyb20gd2hpY2gKICAgdGhlIGNs aWVudCdzIElQdjYgYWRkcmVzcyBvciBwcmVmaXggaXMgYXNzaWduZWQuICBPcHRpb25fUG9vbF9O YW1lIGlzCiAgIHRoZSBzdWItb3B0aW9uIG9mIE9wdGlvbl9BdXRob3JpemF0aW9uLCBvbmUgb3Ig bW9yZSBPcHRpb25fUG9vbF9OYW1lCiAgIG1heSBpbiB0aGUgc2FtZSBjb250YWluZXIgT3B0aW9u X0F1dGhvcml6YXRpb24uICBUaGUgZm9ybWF0IG9mIHRoZQogICBPcHRpb25fUG9vbF9OYW1lIGlz IGRlZmluZWQgYXMgZm9sbG93czoKCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAg ICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg fCAgICAgICAgT3B0aW9uX1Bvb2xfTmFtZSAgICAgICB8ICAgICAgICAgb3B0aW9uLWxlbmd0aCAg ICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIFBvb2wg TmFtZS4uLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwoKICAgb3B0aW9uLWNvZGUgICAgICBPcHRpb25fUG9vbF9OYW1l IChUQkQpCiAgIG9wdGlvbi1sZW5ndGggICAgTGVuZ3RoIG9mIHRoZSBmaWVsZCAnUG9vbCBOYW1l JyBpbiBPY3RldHMKICAgb3B0aW9uLWRhdGEgICAgICBTdHJpbmcgZGF0YSB0eXBlLCBjb250YWlu cyB0aGUgbmFtZSBvZiBhZGRyZXNzCiAgICAgICAgICAgICAgICAgICAgcG9vbCBvciBwcmVmaXgg cG9vbCBjb25maWd1cmVkIG9uIHRoZSBESENQdjYKICAgICAgICAgICAgICAgICAgICBzZXJ2ZXIu CgogICBEaXNjdXNzaW9uOiBUaGVyZSBhcmUgMyBSQURJVVMgYXR0cmlidXRlcyBpbiBzdHJpbmcg ZGF0YSB0eXBlIGFyZQogICBhc3NvY2lhdGVkIHdpdGggdGhlIElQdjYgYWRkcmVzcyBhbmQgSVB2 NiBwcmVmaXggYXNzaWdubWVudCB0aHJvdWdoCiAgIERIQ1B2Ni4gIFRoZXkgYXJlIEZyYW1lZC1Q b29sICg4OCkgZGVmaW5lZCBpbiBbUkZDMjg2OV0sIFN0YXRlZnVsLQogICBJUHY2LUFkZHJlc3Mt UG9vbCwgRGVsZWdhdGVkLUlQdjYtUHJlZml4LVBvb2wgZGVmaW5lZCBpbgogICBbaWV0Zi1yYWRl eHQtaXB2Ni1hY2Nlc3MtMDZdLiAgRG9lcyBpdCBuZWVkIGEgJ1R5cGUnIGZpZWxkIGluIHRoZQog ICBPcHRpb25fUG9vbF9OYW1lPwoKKioqIFlvdSBuZWVkIHRvIHNheSBob3cgdGhlIHN0cmluZyBp cyBlbmNvZGVkOyBJJ2Qgc3VnZ2VzdCBVVEY4IG9yCk5WVC1BU0NJSSwgd2hpY2hldmVyIG1ha2Vz IG1vcmUgc2Vuc2UgdG8geW91LiAgIFVURjggaXMgYmV0dGVyIGlmCml0J3MgcG9zc2libGUsIGJ1 dCBJIGRvbid0IGtub3cgd2hhdCB0aGUgUkFESVVTIHNwZWMgc2F5cy4KCjUuMi4gIE9wdGlvbl9B ZGRyZXNzX1ByZWZpeF9BdXRoCgogICBUaGUgT3B0aW9uX0FkZHJlc3NfUHJlZml4X0F1dGggaXMg dXNlZCB0byBjYXJyeSB0aGUgSVB2NiBhZGRyZXNzIG9yCiAgIHByZWZpeCBzcGVjaWZpZWQgZm9y IHRoZSBjbGllbnRzIGFjY29yZGluZyB0byB0aGUgdXNlciBpbmZvcm1hdGlvbgogICBnb3QgZnJv bSB0aGUgUkFESVVTIGF0dHJpYnV0ZXMsIGluY2x1ZGluZyBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgg KDEyMykKICAgZGVmaW5lZCBpbiBbUkZDNDgxOF0sIEZyYW1lZC1JUHY2LUFkZHJlc3MgZGVmaW5l ZCBpbiBbaWV0Zi1yYWRleHQtCiAgIGlwdjYtYWNjZXNzLTA2XS4gIE9wdGlvbl9BZGRyZXNzX1By ZWZpeF9BdXRoIGlzIHRoZSBzdWItb3B0aW9uIG9mCiAgIE9wdGlvbl9BdXRob3JpemF0aW9uLiAg VGhlIGZvcm1hdCBvZiB0aGUgT3B0aW9uX0FkZHJlc3NfUHJlZml4X0F1dGgKICAgaXMgZGVmaW5l ZCBhcyBmb2xsb3dzOgoKKioqIFdoeSBub3QgaGF2ZSB0d28gb3B0aW9ucyBoZXJlLCBvbmUgYW4g YWRkcmVzcyBhbmQgdGhlIG90aGVyIGEgcHJlZml4PwpJcyB0aGVyZSBhIHJlYXNvbiB3aHkgaXQg bWFrZXMgc2Vuc2UgdG8gb3ZlcmxvYWQgdGhpcyAoZS5nLiwgZG9lcyBSQURJVVMKZG8gaXQgdGhp cyB3YXk/KQoKCgoKWWVoICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgNiwg MjAxMiAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBESENQ djYgQXV0aG9yaXphdGlvbiBPcHRpb24gICAgICAgICAgICBNYXJjaCAyMDEyCgoKICAgIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMK ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICBPcHRpb25fQWRkcmVzc19QcmVmaXhfQXV0aCAg IHwgICAgICAgICBvcHRpb24tbGVuZ3RoICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IHByZWZp eC1sZW5ndGggfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICArLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgIGlwdjYtcHJlZml4LWFkZHJl c3MgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAo MTYgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAg ICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstfAogICB8ICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKwoKICAgb3B0aW9u LWNvZGUgICAgICAgICAgICBPcHRpb25fQWRkcmVzc19QcmVmaXhfQXV0aCAoVEJEKQogICBvcHRp b24tbGVuZ3RoICAgICAgICAgIDE3IGluIE9jdGV0cwogICBwcmVmaXgtbGVuZ3RoICAgICAgICAg IExlbmd0aCBvZiB0aGUgcHJlZml4IGluIGJpdHM7IGlmIHRoZQogICAgICAgICAgICAgICAgICAg ICAgICAgIHByZWZpeC1sZW5ndGggaXMgMTI4LCB0aGVuIHRoZSB2YWx1ZSBpbgogICAgICAgICAg ICAgICAgICAgICAgICAgIHRoZSBmb2xsb3dpbmcgJ2lwdjYtcHJlZml4LWFkZHJlc3MnIGZpZWxk CiAgICAgICAgICAgICAgICAgICAgICAgICAgbWVhbnMgYW4gSVB2NiBhZGRyZXNzCiAgIGlwdjYt cHJlZml4LWFkZHJlc3MgICAgQSBzcGVjaWZpZWQgZGVsZWdhdGVkIElQdjYgcHJlZml4IG9yIGFu CiAgICAgICAgICAgICAgICAgICAgICAgICAgYXNzaWduZWQgSVB2NiBhZGRyZXNzCgoKNi4gIFJl bGF5IEFnZW50IEJlaGF2aW9yCgogICBUaGUgREhDUHY2IHJlbGF5IGFnZW50IG11c3QgaW5jbHVk ZSBPcHRpb25fQXV0aG9yaXphdGlvbiBpbiB0aGUKICAgcmVsYXktZm9yd2FyZCAoMTIpIG1lc3Nh Z2UgYWNjb3JkaW5nIHRvIHRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uCiAgIG9uIHRoZSBz cGVjaWZpZWQgcG9vbCBjb25maWd1cmVkLCBhZGRyZXNzIGFzc2lnbmVkIG9yIHByZWZpeAogICBk ZWxlZ2F0ZWQgaW4gdGhlIEFjY2Vzcy1BY2NlcHQgbWVzc2FnZSBvZiBSQURJVVMuICBXaGVuIHRo ZSB2YWx1ZSBpbgogICB0aGUgYXR0cmlidXRlcyBvZiBGcmFtZWQtUG9vbCAoODgpLCBTdGF0ZWZ1 bC1JUHY2LUFkZHJlc3MtUG9vbCBhbmQKICAgRGVsZWdhdGVkLUlQdjYtUHJlZml4LVBvb2wgaW5j bHVkZWQgaW4gdGhlIEFjY2Vzcy1BY2NlcHQgbWVzc2FnZQogICByZXBsaWVkIGZyb20gUkFESVVT IHNlcnZlciBpcyB2YWxpZCwgdGhlIHJlbGF5IGFnZW50IHNoYWxsIGluY2x1ZGUKICAgT3B0aW9u X1Bvb2xfTmFtZSBpbiB0aGUgY29udGFpbmVyIE9wdGlvbl9BdXRob3JpemF0aW9uOyB3aGVuIHRo ZQogICB2YWx1ZSBpbiB0aGUgYXR0cmlidXRlcyBvZiBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXggKDEy MykgYW5kIEZyYW1lZC0KICAgSVB2Ni1BZGRyZXNzIGluY2x1ZGVkIGluIHRoZSBBY2Nlc3MtQWNj ZXB0IG1lc3NhZ2UgcmVwbGllZCBmcm9tCiAgIFJBRElVUyBzZXJ2ZXIgaXMgdmFsaWQsIHRoZSBy ZWxheSBhZ2VudCBzaGFsbCBpbmNsdWRlCiAgIE9wdGlvbl9BZGRyZXNzX1ByZWZpeF9BdXRoIGlu IHRoZSBjb250YWluZXIgT3B0aW9uX0F1dGhvcml6YXRpb24uCioqKiBPa2F5LCBzbyBSQURJVVMg ZG9lcyBpdCB0aGUgc2FtZSB3YXkgSSdkIHN1Z2dlc3QgZG9pbmcgaXQgZm9yIERIQ1AuCgoKNy4g IFNlcnZlciBCZWhhdmlvcgoKICAgVGhlIERIQ1B2NiBzZXZlciBtdXN0IGRlbGVnYXRlIElQdjYg cHJlZml4IG9yIGFzc2lnbiBJUHY2IGFkZHJlc3MgdG8KICAgdGhlIERIQ1B2NiBjbGllbnQgYWNj b3JkaW5nIHRvIHRoZSBpbmZvcm1hdGlvbiBnb3QgZnJvbQogICBPcHRpb25fQXV0aG9yaXphdGlv bi4Kcy9zZXZlci9zZXJ2ZXIvCnMvSVB2NiBQcmVmaXgvdGhlIElQdjYgcHJlZml4LwpzL0lQdjYg YWRkcmVzcy90aGUgSVB2NiBhZGRyZXNzLwoKKioqIFRoaXMgcmVhbGx5IGlzbid0IGtvc2hlci4g ICBESENQIHNlcnZlcnMgZG8gYWRkcmVzcyBhbGxvY2F0aW9uLApub3QgcmVsYXkgYWdlbnRzLiAg IElmIHRoZSBSQURJVVMgc2VydmVyIGFjdHVhbGx5IGNvbnRyb2xzIGFkZHJlc3MKYWxsb2NhdGlv biwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYSBESENQIHNlcnZlci4KCldoYXQgeW91IGhhdmUgaGVy ZSBpcyBlc3NlbnRpYWxseSBhIHN0YXRlbGVzcy1vbmx5IERIQ1Agc2VydmVyIHRoYXQKaXMgcHJl dGVuZGluZyB0byBiZSBzdGF0ZWZ1bCBpbiBvcmRlciB0byBzdXBwb3J0IGEgcGFydGljdWxhciBk ZXBsb3ltZW50CnNjZW5hcmlvLiAgIEkgdGhpbmsgdGhpcyBpcyBhIGJhZCBpZGVhLiAgIFdoYXQg eW91IHJlYWxseSB3YW50IHRvIGRvCmhlcmUgaXMgdG8gaGF2ZSBhIHRydWx5IHN0YXRlbGVzcyBE SENQdjYgc2VydmVyIGluIHRoZSBjZW50cmFsIGxvY2F0aW9uCnRoYXQgY2FuIHByb3ZpZGUgdGhl IHN0YXRlbGVzcyBpbmZvcm1hdGlvbiwgYnV0IGhhdmUgYSBzdGF0ZWZ1bApESENQdjYgc2VydmVy IGluIHRoZSBOQVMsIG5vdCBhIHJlbGF5IGFnZW50LiAgIFNvIGVpdGhlciB0aGUgTkFTCmRvZXMg c3RhdGVsZXNzIERIQ1B2NiB0byBnZXQgdGhlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gYW5k IHNlbmQKaXQgdG8gdGhlIGNsaWVudCwgb3IgZWxzZSB0aGUgY2xpZW50IGZpcnN0IGRvZXMgc3Rh dGVmdWwgREhDUHY2IHRvCmdldCBpdHMgYWRkcmVzcyBvciBwcmVmaXgsIGFuZCB0aGVuIGRvZXMg c3RhdGVsZXNzIHRvIGdldCBvdGhlcgpjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuCgpJIGNhbiBz ZWUgd2h5IHlvdSBjaG9zZSB0aGUgc29sdXRpb24geW91IGRpZC4gICBJJ20gb2JqZWN0aW5nIHRv IHlvdXIKd2F5IG9mIHNvbHZpbmcgdGhlIHByb2JsZW0sIGJ1dCB0aGUgd2F5cyBJIGhhdmUgcHJv cG9zZWQgYXJlIG5vdCByZWFsbHkKbXVjaCBiZXR0ZXIuCgpJdCB3b3VsZCBhbHNvIGJlIHBvc3Np YmxlIHRvIGhhdmUgdGhlIE5BUyBmb3J3YXJkIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQKdG8gZG8g dGhlIFJBRElVUyBsb29rdXAgdG8gdGhlIERIQ1Agc2VydmVyLCBhbmQgdGhlbiBoYXZlIHRoZSBE SENQIHNlcnZlcgpkbyB0aGUgUkFESVVTIHF1ZXJ5LCBidXQgdGhlIHByb2JsZW0gd2l0aCB0aGlz IGlzIHRoYXQgeW91IHN0aWxsIGhhdmUgYQpjdXN0b20gREhDUCBzZXJ2ZXIsIGFuZCB0aGlzIG1h a2VzIG1vcmUgc2Vuc2UgaW4gdGhlIE5BUyB0aGFuIGluIHRoZQpjZW50ZXIgb2YgdGhlIG5ldHdv cmsuCQoKQW55d2F5LCB0aGlzIGlzIHNvbWV0aGluZyB3ZSBjYW4gZGlzY3VzcyBpbiB0aGUgd29y a2luZyBncm91cC4gICBJIHRoaW5rCndoYXQgeW91IGFyZSB0cnlpbmcgdG8gZG8gaGVyZSBpcyBh IGdvb2QgaWRlYTsgdGhlIHF1ZXN0aW9uIGlzLCBob3cgdG8gCmRvIGl0IGluIHN1Y2ggYSB3YXkg dGhhdCB3ZSBkb24ndCBjcmVhdGUgYSB3aG9sZSBuZXcga2luZCBvZiBESENQCnNlcnZlcj8KCgoK CgoKWWVoICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgNiwgMjAxMiAgICAg ICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBESENQdjYgQXV0aG9y aXphdGlvbiBPcHRpb24gICAgICAgICAgICBNYXJjaCAyMDEyCgoKOC4gIENsaWVudCBCZWhhdmlv cgoKICAgT3B0aW9uX0F1dGhvcml6YXRpb24gaXMgb25seSBleGNoYW5nZWQgYmV0d2VlbiB0aGUg cmVsYXkgYWdlbnRzIGFuZAogICB0aGUgc2VydmVycywgc28gY2xpZW50cyBhcmUgbmV2ZXIgYXdh cmUgb2YgaXRzIHVzZS4KCgo5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIEtub3duIHNl Y3VyaXR5IHZ1bG5lcmFiaWxpdGllcyBvZiB0aGUgREhDUHY2IHByb3RvY29sIG1heSBhcHBseSB0 bwogICBpdHMgb3B0aW9ucy4gIFNlY3VyaXR5IGlzc3VlcyByZWxhdGVkIERIQ1B2NiBhcmUgZGVz Y3JpYmVkIGluIHNlY3Rpb24KICAgMjMgb2YgW1JGQzMzMTVdCgoKMTAuICBJQU5BIENvbnNpZGVy YXRpb25zCgogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBhc3NpZ24gdGhlIG9wdGlvbiBjb2RlIHRv IE9wdGlvbl9BdXRob3JpemF0aW9uCiAgIGFuZCBpdHMgc3ViLW9wdGlvbnMgb2YgT3B0aW9uX1Bv b2xfTmFtZSwgT3B0aW9uX0FkZHJlc3NfUHJlZml4X0F1dGgKICAgZnJvbSB0aGUgIkRIQ1B2NiBh bmQgREhDUHY2IG9wdGlvbnMiIHJlZ2lzdHJ5IChodHRwOi8vd3d3LmlhbmEub3JnLwogICBhc3Np Z25tZW50cy9kaGNwdjYtcGFyYW1ldGVycy9kaGNwdjYtcGFyYW1ldGVycy54bWwpLgoKCjExLiAg QWNrbm93bGVkZ2VtZW50cwoKICAgVEJECgoKMTIuICBSZWZlcmVuY2VzCgoxMi4xLiAgTm9ybWF0 aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxz IiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkMyODY1XSAgUmlnbmV5LCBD LiwgV2lsbGVucywgUy4sIFJ1YmVucywgQS4sIGFuZCBXLiBTaW1wc29uLAogICAgICAgICAgICAg ICJSZW1vdGUgQXV0aGVudGljYXRpb24gRGlhbCBJbiBVc2VyIFNlcnZpY2UgKFJBRElVUykiLAog ICAgICAgICAgICAgIFJGQyAyODY1LCBKdW5lIDIwMDAuCgogICBbUkZDMjg2OV0gIFJpZ25leSwg Qy4sIFdpbGxhdHMsIFcuLCBhbmQgUC4gQ2FsaG91biwgIlJBRElVUwogICAgICAgICAgICAgIEV4 dGVuc2lvbnMiLCBSRkMgMjg2OSwgSnVuZSAyMDAwLgoKICAgW1JGQzMxNjJdICBBYm9iYSwgQi4s IFpvcm4sIEcuLCBhbmQgRC4gTWl0dG9uLCAiUkFESVVTIGFuZCBJUHY2IiwKICAgICAgICAgICAg ICBSRkMgMzE2MiwgQXVndXN0IDIwMDEuCgogICBbUkZDMzMxNV0gIERyb21zLCBSLiwgQm91bmQs IEouLCBWb2x6LCBCLiwgTGVtb24sIFQuLCBQZXJraW5zLCBDLiwKICAgICAgICAgICAgICBhbmQg TS4gQ2FybmV5LCAiRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yCiAgICAg ICAgICAgICAgSVB2NiAoREhDUHY2KSIsIFJGQyAzMzE1LCBKdWx5IDIwMDMuCgogICBbUkZDMzYz M10gIFRyb2FuLCBPLiBhbmQgUi4gRHJvbXMsICJJUHY2IFByZWZpeCBPcHRpb25zIGZvciBEeW5h bWljCgoKClllaCAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDYsIDIwMTIg ICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgREhDUHY2IEF1 dGhvcml6YXRpb24gT3B0aW9uICAgICAgICAgICAgTWFyY2ggMjAxMgoKCiAgICAgICAgICAgICAg SG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIChESENQKSB2ZXJzaW9uIDYiLCBSRkMgMzYzMywK ICAgICAgICAgICAgICBEZWNlbWJlciAyMDAzLgoKICAgW1JGQzM2NDZdICBEcm9tcywgUi4sICJE TlMgQ29uZmlndXJhdGlvbiBvcHRpb25zIGZvciBEeW5hbWljIEhvc3QKICAgICAgICAgICAgICBD b25maWd1cmF0aW9uIFByb3RvY29sIGZvciBJUHY2IChESENQdjYpIiwgUkZDIDM2NDYsCiAgICAg ICAgICAgICAgRGVjZW1iZXIgMjAwMy4KCiAgIFtSRkMzNzM2XSAgRHJvbXMsIFIuLCAiU3RhdGVs ZXNzIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sCiAgICAgICAgICAgICAgKERI Q1ApIFNlcnZpY2UgZm9yIElQdjYiLCBSRkMgMzczNiwgQXByaWwgMjAwNC4KCiAgIFtSRkM0MDE0 XSAgRHJvbXMsIFIuIGFuZCBKLiBTY2huaXpsZWluLCAiUmVtb3RlIEF1dGhlbnRpY2F0aW9uCiAg ICAgICAgICAgICAgRGlhbC1JbiBVc2VyIFNlcnZpY2UgKFJBRElVUykgQXR0cmlidXRlcyBTdWJv cHRpb24gZm9yIHRoZQogICAgICAgICAgICAgIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFBy b3RvY29sIChESENQKSBSZWxheSBBZ2VudAogICAgICAgICAgICAgIEluZm9ybWF0aW9uIE9wdGlv biIsIFJGQyA0MDE0LCBGZWJydWFyeSAyMDA1LgoKICAgW1JGQzQ4MThdICBTYWxvd2V5LCBKLiBh bmQgUi4gRHJvbXMsICJSQURJVVMgRGVsZWdhdGVkLUlQdjYtUHJlZml4CiAgICAgICAgICAgICAg QXR0cmlidXRlIiwgUkZDIDQ4MTgsIEFwcmlsIDIwMDcuCgoxMi4yLiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcwoKICAgW2lldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA2XQogICAgICAgICAgICAgIExv dXJkZWxldCwgQi4sIERlYywgVy4sIFNhcmlrYXlhLCBCLiwgWm9ybiwgRy4sIGFuZCBELgogICAg ICAgICAgICAgIE1pbGVzLCAiUkFESVVTIGF0dHJpYnV0ZXMgZm9yIElQdjYgQWNjZXNzIE5ldHdv cmtzIiwKICAgICAgICAgICAgICBKdWx5IDIwMTEuCgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgTGVh ZiBZLiBZZWggKGVkaXRvcikKICAgSHVhd2VpIFRlY2hub2xvZ2llcwogICBTaGVuemhlbgogICBQ LiBSLiBDaGluYQoKICAgUGhvbmU6ICs4Ni03NTUtMjg5Nzg4NTEKICAgRW1haWw6IGxlYWYueS55 ZWhAaHVhd2VpLmNvbQoKCgoKCgoKCgoKCgoKCgoKWWVoICAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgNiwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDldCgwK --_002_8D23D4052ABE7A4490E77B1A012B6307472D0C15mbx01winnominum_-- From volz@cisco.com Wed Mar 28 04:28:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47B421F88E6 for ; Wed, 28 Mar 2012 04:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.219 X-Spam-Level: X-Spam-Status: No, score=-8.219 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzM0LkfoRMnP for ; Wed, 28 Mar 2012 04:28:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 179FC21F88E1 for ; Wed, 28 Mar 2012 04:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1026; q=dns/txt; s=iport; t=1332934102; x=1334143702; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=0U047vfb5hY7kgyjgoZTlymWYfUEFg0FNNZgLPhHTmk=; b=ceW0e/Y72jP1CCpvhG/IxJDbruhpR9IUvlYMVL8IbBbWa7cwOJRkOJ5l b0vAWRwcTDKRzZDNlpljfH6tANxbVLB6q0/z5nSSrv+mU2i2DxJuBQ0pH 6VaCoN5WYE7jbwOscxLLFoHDi+rCm8YpLxBnSqtD6+JUkPYTT0wnNbgja c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkIAI70ck+tJXG8/2dsb2JhbABFuGsCgQeCCQEBAQMBAQEBDwEnNAsFCwIBCEYnJwkBAQQTIodjBQubV58XBJAvYwSVYY5FgWiDAw X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="70047166" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 28 Mar 2012 11:28:21 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2SBSLIT004882; Wed, 28 Mar 2012 11:28:21 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 06:28:21 -0500 Received: from 72.163.62.204 ([72.163.62.204]) by XMB-RCD-101.cisco.com ([72.163.62.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Mar 2012 11:28:20 +0000 References: <8D23D4052ABE7A4490E77B1A012B6307472D0C15@mbx-01.win.nominum.com> Content-Transfer-Encoding: quoted-printable From: "Bernie Volz (volz)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D0C15@mbx-01.win.nominum.com> thread-topic: [dhcwg] FW: New VersionNotification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt thread-index: Ac0M1eEoKlNxKNt5SKW9QoqceM239g== Message-ID: Date: Wed, 28 Mar 2012 07:28:23 -0400 To: "Ted Lemon" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 28 Mar 2012 11:28:21.0438 (UTC) FILETIME=[E17F0DE0:01CD0CD5] Cc: dhc WG Subject: Re: [dhcwg] FW: New VersionNotification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:28:22 -0000 Regard Ted's comment: *** There is no reason to use either suboptions or RADIUS options. The right thing to do is simply define a DHCP option to carry each RADIUS attrib= ute that you think the DHCP server might need. Sub-options are common in DHCPv= 4 because there are only 256 option codes possible, but in DHCPv6 this is not a= problem, and the additional complexity introduced by suboptions is undesirab= le. I fully agree. I had always thought it good if we had a v6 equivalent of RFC= 4014. Jusy a container for comminicating a subset of the RADIUS attributes w= ould work very well. - Bernie Sent from my iPad On Mar 28, 2012, at 6:49 AM, "Ted Lemon" wrote: > I had a chance to give the draft a thorough read yesterday; I've attached c= omments and proposed edits. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Mar 28 05:02:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDF121F8702 for ; Wed, 28 Mar 2012 05:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lv6VlPW+18i for ; Wed, 28 Mar 2012 05:02:33 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D8C1721F842E for ; Wed, 28 Mar 2012 05:02:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT3L9wlo1vuKn10HB8hEMKv9cCmqFOfQK@postini.com; Wed, 28 Mar 2012 05:02:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D04D11B811B for ; Wed, 28 Mar 2012 05:02:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7D91F190064; Wed, 28 Mar 2012 05:02:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 28 Mar 2012 05:02:09 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] FW: New VersionNotification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt Thread-Index: AQHNDNXkeyBo8/ocaEWMyurXscwD7ZZ/mzk0 Date: Wed, 28 Mar 2012 12:02:07 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D1C76@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307472D0C15@mbx-01.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] FW: New VersionNotification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:02:34 -0000 > I fully agree. I had always thought it good if we had a v6 equivalent > of RFC 4014. Jusy a container for comminicating a subset of the > RADIUS attributes would work very well. That's not actually what I was suggesting, but okay. The main issue with this draft, though, is a simple one: is this the right = architecture to solve the problem described in the introduction? From volz@cisco.com Wed Mar 28 05:15:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AFA21E81A4 for ; Wed, 28 Mar 2012 05:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.162 X-Spam-Level: X-Spam-Status: No, score=-8.162 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s4JDwA8dhxu for ; Wed, 28 Mar 2012 05:15:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5E51721E8196 for ; Wed, 28 Mar 2012 05:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=907; q=dns/txt; s=iport; t=1332936903; x=1334146503; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=Vi2+t9Nq0NPIb+HXJKthwqrV4mOE7sLdaUcWh17bh6I=; b=Lbi6DvJnjsfnDju0k4P7mh7Bl6dumHyvVK+RKAd76t0/B3L8lXMe6f4S QdYxYN8HLUMEZPAKFbkO7eTdasDBKJFaCbvkklHqVZMkAdaZXE9tzKaEa MLqOsDTtqxZmuwx88Uo/oLVeDQBoMOqRseAolDnYM89eVKFS3uJvzkH9v Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokIALz/ck+tJXHA/2dsb2JhbABFigauZQKBB4IJAQEBAwESASc/EAIBCBI0SQUJAQEEEyKHYwWbWJ8dkC9jBJVhjkWBaIMD X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="70073185" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 28 Mar 2012 12:15:03 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2SCF2mG005112; Wed, 28 Mar 2012 12:15:03 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 07:15:02 -0500 Received: from 72.163.63.13 ([72.163.63.13]) by XMB-RCD-101.cisco.com ([72.163.62.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Mar 2012 12:15:02 +0000 References: <8D23D4052ABE7A4490E77B1A012B6307472D0C15@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D1C76@mbx-01.win.nominum.com> Content-Transfer-Encoding: quoted-printable From: "Bernie Volz (volz)" Content-Type: text/plain; charset="us-ascii" Thread-Topic: [dhcwg] FW: New VersionNotification fordraft-yeh-dhc-dhcpv6-authorization-opt-00.txt Thread-Index: Ac0M3GcSn60rwbX1TN6cYk9ZQ9/5qw== In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D1C76@mbx-01.win.nominum.com> Message-ID: <8E1E6B16-2FF8-4971-A143-179CE7BF31B1@cisco.com> Date: Wed, 28 Mar 2012 08:15:05 -0400 To: "Ted Lemon" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 28 Mar 2012 12:15:02.0849 (UTC) FILETIME=[67447310:01CD0CDC] Cc: dhc WG Subject: Re: [dhcwg] FW: New VersionNotification fordraft-yeh-dhc-dhcpv6-authorization-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:15:05 -0000 I guess the core question is how is this different from 4014 (other than the= obvious ones related to different DHCP versions)? The intro text is very di= fferent, but aren't they both trying to do the same thing? That of course be= gs the question as to what is wrong with the 4014 text (appropriately adjust= ed for v6). If this is trying to do something different, it certainly isn't c= lear to me. Sent from my iPad On Mar 28, 2012, at 8:02 AM, "Ted Lemon" wrote: >> I fully agree. I had always thought it good if we had a v6 equivalent >> of RFC 4014. Jusy a container for comminicating a subset of the >> RADIUS attributes would work very well. >=20 > That's not actually what I was suggesting, but okay. >=20 > The main issue with this draft, though, is a simple one: is this the right= architecture to solve the problem described in the introduction? From leaf.y.yeh@huawei.com Wed Mar 28 07:05:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE24221E824B for ; Wed, 28 Mar 2012 07:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MyAZTKMrhQa for ; Wed, 28 Mar 2012 07:05:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8740921E808E for ; Wed, 28 Mar 2012 07:05:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEL53744; Wed, 28 Mar 2012 10:05:35 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 07:03:09 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 07:03:13 -0700 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.75]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Wed, 28 Mar 2012 22:03:08 +0800 From: Leaf yeh To: Ted Lemon Thread-Topic: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt Thread-Index: AQHNDNBPZKAXl95iTE6kUm0fOpBKvZZ/jsKkgAAuYXWAAAA7Wg== Date: Wed, 28 Mar 2012 14:03:08 +0000 Message-ID: <99ED2276-8625-4405-9BE1-2AD4841D83F1@mimectl> References: , <8D23D4052ABE7A4490E77B1A012B6307472D0C15@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D0C15@mbx-01.win.nominum.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: multipart/alternative; boundary="_000_99ED2276862544059BE12AD4841D83F1mimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG Subject: Re: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:05:37 -0000 --_000_99ED2276862544059BE12AD4841D83F1mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Ted Thanks for your comments of the quick review and text revisions after '/s'.= I will update these revision in the '-01'. Ted - *** There is no reason to use either suboptions or RADIUS options. = The right thing to do is simply define a DHCP option to carry each RADIUS attri= bute that you think the DHCP server might need. Sub-options are common in DHCP= v4 because there are only 256 option codes possible, but in DHCPv6 this is not= a problem, and the additional complexity introduced by suboptions is undesira= ble. Section 4 of this draft raised the discussion on the option design. Design-= 1 employs the sub-option; Design-2 employs the same method of RFC4014. Hope= we could figure out the best design in the WG. The code space of DHCPv6 op= tion is 2-octect, so we don't need to worry about the exhaustion of DHCPv6 = option codes. The draft could request the option code for Option_Pool_Name,= Option_Address_Prefix_Auth from the same space for Option_Authorization, s= uch as OPTION_IAPREFIX(26) in OPTION_IA_PD(25), or OPTION_IAADDR(5) in OPTI= ON_IA_NA(3). That means the concept of sub-option is not necessary in this = draft, the 'contained option' might be the substitute for the text. Ted - *** So, the following should all just be DHCPv6 options, and there sh= ould be no Option_Authorization option. The following (Option_Pool_Name, Option_Address_Prefix_Auth ) could be DHCP= v6 options, and also could be the 'contained option' in the 'container opti= on', Option_Authorization. Ted - *** You need to say how the string is encoded; I'd suggest UTF8 or NVT-ASCII, whichever makes more sense to you. UTF8 is better if it's possible, but I don't know what the RADIUS spec says. The defintion of RADIUS attribute 'Framed-Pool' in the setion 5.18 of RFC28= 69 is quoted as 'The string field contains the name of an assigned address = pool configured on the NAS.'. The defintion of RADIUS attribute 'Framed-IPv= 6-Pool' in the setion 2.6 of RFC3316 is quoted as 'The string field contai= ns the name of an assigned IPv6 prefix pool configured on the NAS. The fiel= d is not NUL (hex 00) terminated.'. The definetion of 'string'data type in = RADIUS attribute can be found in section 5 of RFC2865 and section 2.1 of RF= C6158, quoted as '8-bit binary data'. UTF-8 is used in 'text' data type of = RADIUS. Ted - *** Why not have two options here, one an address and the other a pre= fix? Is there a reason why it makes sense to overload this (e.g., does RADIUS do it this way?) No special reason here, just supposed the address and the prefix could be p= resented in the unified format. I am ok with re-define 2 options here. RADI= US employs one data type for 'IPv6 address' and the other data type for 'IP= v6 prefix' per the section 2.1 of RFC6158 (or the section 2.1, 2.3 of RFC31= 62). Ted - *** Okay, so RADIUS does it the same way I'd suggest doing it for DHC= P. Ted - *** This really isn't kosher. DHCP servers do address allocation, not relay agents. If the RADIUS server actually controls address allocation, there is no need for a DHCP server. As mentioned in section 6 of this draft, the relay includes Option_Authoriz= ation per the RADIUS attrbutes in the message of 'Access-Accept'. The serve= r will respond (or do address allocation) per the indication in Option_Auth= orization, as the same behavior when the server locates on the NAS (BRAS). = In fact, the idea in this draft expects the sever only do the address/prefi= x allocation. Hope it is clarified. Best Regards, Leaf From: Ted Lemon [Ted.Lemon@nominum.com] Sent: Wednesday, March 28, 2012 18:48 To: Leaf yeh; dhc WG Subject: RE: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-= authorization-opt-00.txt I had a chance to give the draft a thorough read yesterday; I've attached c= omments and proposed edits. --_000_99ED2276862544059BE12AD4841D83F1mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0F1BA443E80D6A4E801B877580B8D7DE@huawei.com> Content-Transfer-Encoding: quoted-printable

Hi, Ted

Thanks for your comments of the quick review and text revisions after = '/s'. I will update these revision in the '-01'.

Ted  - *** There is no reason to use either suboptions or RADIUS optio= ns.   The
right thing to do is simply define a DHCP option to carry each RADIUS attri= bute
that you think the DHCP server might need.   Sub-options are comm= on in DHCPv4
because there are only 256 option codes possible, but in DHCPv6 this is not= a
problem, and the additional complexity introduced by suboptions is undesira= ble.

Section 4 of this draft raised the discussion on the option design. Design-= 1 employs the sub-option; Design-2 employs the same method of RFC4014. Hope= we could figure out the best design in the WG. The code space of DHCPv6 op= tion is 2-octect, so we don't need to worry about the exhaustion of DHCPv6 option codes. The draft could requ= est the option code for Option_Pool_Name, Option_Address_Prefix_Auth from t= he same space for Option_Authorization, such as OPTION_IAPREFIX(26) in OPTI= ON_IA_PD(25), or OPTION_IAADDR(5) in OPTION_IA_NA(3). That means the concept of sub-option is not necessary = in this draft, the 'contained option' might be the substitute for the text.=


Ted - *** So, the following should all just be DHCPv6 options, and there sh= ould be
no Option_Authorization option.

The following (Option_Pool_Name, Option_Address_Prefix_Auth ) could be DHCP= v6 options, and also could be the 'contained option' in the 'container opti= on', Option_Authorization.


Ted - *** You need to say how the string is encoded; I'd suggest UTF8 or NVT-ASCII, whichever makes more sense to you.   UTF8 is better if=
it's possible, but I don't know what the RADIUS spec says.

The defintion of RADIUS attribute 'Framed-Pool' in the setion 5.18 of = RFC2869 is quoted as 'The string field contains the name of an assigned add= ress pool configured on the NAS.'. The defintion of RADIUS attribute '= Framed-IPv6-Pool' in the setion 2.6 of RFC3316  is quoted as 'The string field contains the name of an assigned IPv6 = prefix pool configured on the NAS. The field is not NUL (hex 00) = terminated.'. The definetion of 'string'data type in RADIUS attribute = can be found in section 5 of RFC2865 and section 2.1 of RFC6158, quoted as '8-bit binary data'. UTF-8 is used in 'text' da= ta type of RADIUS.


Ted - *** Why not have two options here, one an address and the other = a prefix?
Is there a reason why it makes sense to overload this (e.g., does RADIUS do it this way?)

No special reason here, just supposed the address and the prefix could b= e presented in the unified format. I am ok with re-define 2 options here. R= ADIUS employs one data type for 'IPv6 address' and the other data type= for 'IPv6 prefix' per the section 2.1 of RFC6158 (or the section 2.1, 2.3 of RFC3162).


Ted - *** Okay, so RADIUS does it the same way I'd suggest doing it for DHC= P.

Ted - *** This really isn't kosher.   DHCP servers do address all= ocation,
not relay agents.   If the RADIUS server actually controls addres= s
allocation, there is no need for a DHCP server.

 

As mentioned in section 6 of this draft, the relay includes Option_Autho= rization per the RADIUS attrbutes in the message of 'Access-Accept'. The se= rver will respond (or do address allocation) per the indication in Opt= ion_Authorization, as the same behavior when the server locates on the NAS (BRAS). In fact, the idea in this draft= expects the sever only do the address/prefix allocation. Hope it is clarif= ied.

 

 

Best Regards,
Leaf




From: Ted Lemon [Ted.Lemon@nominum.com]
Sent: Wednesday, March 28, 2012 18:48
To: Leaf yeh; dhc WG
Subject: RE: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-= authorization-opt-00.txt


I had a chance to give the draft a thorough read yesterday; I've attached c= omments and proposed edits.

--_000_99ED2276862544059BE12AD4841D83F1mimectl_-- From Ted.Lemon@nominum.com Wed Mar 28 07:23:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D22621F884C for ; Wed, 28 Mar 2012 07:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.48 X-Spam-Level: X-Spam-Status: No, score=-106.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBXb5iTzpiNr for ; Wed, 28 Mar 2012 07:23:14 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 22BF121F87B1 for ; Wed, 28 Mar 2012 07:23:06 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT3MeyaazJXgDuOM1hppbQo++nl9ky1fA@postini.com; Wed, 28 Mar 2012 07:23:06 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 34A0D1B80D9 for ; Wed, 28 Mar 2012 07:23:05 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 21FBD190064; Wed, 28 Mar 2012 07:23:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 28 Mar 2012 07:23:05 -0700 From: Ted Lemon To: Leaf yeh Thread-Topic: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt Thread-Index: AQHNDOvelduVC3YdRku65Xf6jWfOvJZ/wPV/ Date: Wed, 28 Mar 2012 14:23:04 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D1D38@mbx-01.win.nominum.com> References: , <8D23D4052ABE7A4490E77B1A012B6307472D0C15@mbx-01.win.nominum.com>, <99ED2276-8625-4405-9BE1-2AD4841D83F1@mimectl> In-Reply-To: <99ED2276-8625-4405-9BE1-2AD4841D83F1@mimectl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:23:16 -0000 > Thanks for your comments of the quick review and text revisions after '/s= '. I will update these revision in the '-01'. Great, thanks! > Section 4 of this draft raised the discussion on the option design.=20 > Design-1 employs the sub-option; Design-2 employs the same method > of RFC4014. Hope we could figure out the best design in the WG. The > code space of DHCPv6 option is 2-octect, so we don't need to worry > about the exhaustion of DHCPv6 option codes. The draft could request > the option code for Option_Pool_Name, Option_Address_Prefix_Auth > from the same space for Option_Authorization, such as > OPTION_IAPREFIX(26) in OPTION_IA_PD(25), or OPTION_IAADDR(5) > in OPTION_IA_NA(3). That means the concept of sub-option is not > necessary in this draft, the 'contained option' might be the substitute f= or the text. It seems that Bernie is arguing in favor of Design-2. I don't have a stro= ng opinion on this, other than that it seems as if you want to emphasize th= e specific options you mention in your draft, and so from that perspective = it makes sense to simply send them as DHCP options. However, I do not understand why you need to encapsulate these options. D= oesn't this just waste space in the DHCP packet for no purpose? > quoted as '8-bit binary data'. UTF-8 is used in 'text' data type of RADIU= S. Okay, so if the RADIUS option is binary data, you should say "8-bit binary = data" in the DHCP option definition. If it's text, you should say "UTF-8 = encoded text" in the DHCP option definition. But you can't just say "text= ." > I am ok with re-define 2 options here. RADIUS employs one data type for=20 >'IPv6 address' and the other data type for 'IPv6 prefix' per the section > 2.1 of RFC6158 (or the section 2.1, 2.3 of RFC3162). Great, thanks! > As mentioned in section 6 of this draft, the relay includes Option_Author= ization > per the RADIUS attrbutes in the message of 'Access-Accept'. The server wi= ll respond > (or do address allocation) per the indication in Option_Authorization, as= the same > behavior when the server locates on the NAS (BRAS). In fact, the idea in = this draft > expects the sever only do the address/prefix allocation. Hope it is clari= fied. I may have expressed myself poorly. I am not asking you to clarify how it= works. I am saying that I don't agree that it should work that way, and = I would like the working group to consider the architecture you are proposi= ng, and the two other architectures I proposed in my comments, and make a d= ecision as to which architecture to use. I understand that you are advoca= ting the particular architecture you describe in the draft, and that's fine= , but the working group should consider this question. From cuiyang@huawei.com Wed Mar 28 08:48:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A866821E82A6 for ; Wed, 28 Mar 2012 08:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.774 X-Spam-Level: * X-Spam-Status: No, score=1.774 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78diopRKQjNN for ; Wed, 28 Mar 2012 08:48:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 209EE21E826C for ; Wed, 28 Mar 2012 08:48:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET62986; Wed, 28 Mar 2012 11:48:32 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 08:47:13 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 08:47:10 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Wed, 28 Mar 2012 23:46:15 +0800 From: Cui Yang To: Ted Lemon , Alper Yegin , dhc WG Thread-Topic: [dhcwg] draft-bi-dhc-sec-option Thread-Index: AQHNDEv5iTILqwgG4EabUrbxfUEvZ5Z/0S6a Date: Wed, 28 Mar 2012 15:47:05 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2161F479B8F@SZXEML508-MBS.china.huawei.com> References: , <2F208A97-BFF3-4820-BA98-3E47AC41D992@yegin.org>, <8D23D4052ABE7A4490E77B1A012B6307472C3E6F@mbx-02.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472C3E6F@mbx-02.win.nominum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.67] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] draft-bi-dhc-sec-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:48:33 -0000 SGksIFRlZCBhbmQgQWxwZXIsCgpUaGFua3MgZm9yIHlvdXIgcmV2aWV3cyBhbmQgY29tbWVudHMu CgpUaGUgcHJvcG9zZWQgREhDUCBvcHRpb24gaXMgYWltZWQgdG8gaGVscCBzZXQgdXAgdGhlIHNl Y3VyaXR5IG1lY2hhbmlzbSwgaS5lLiwgY2FycnlpbmcgSVAgYWRkcmVzc2VzIG9mIFBLSSBzZXJ2 ZXIsIGV0Yy4gCkJ1dCB0aGUgb3B0aW9uIGl0c2VsZiBkb2VzIG5vdCBuZWVkIHRvIGJlIHByb3Rl Y3RlZCwgb3IgaW4gb3RoZXIgd29yZHMsIHRoZSBzZWN1cml0eSBkb2VzIG5vdCBuZWNlc3Nhcmls eSByZWx5IG9uIHRoZSBESENQIG9wdGlvbi4KClRoZSBjdXJyZW50IHVzYWdlIG9mIHZlbmRvci1z cGVjaWZpYyBzb2x1dGlvbiAob3B0aW9uIDQzKSBmb3IgdGhpcyBwcm9ibGVtIGlzIHF1aXRlIHJl c3RyaWN0ZWQsIGJlY2F1c2Ugb2YgdGhlIHVzdWFsIGxpbWl0YXRpb25zIG9mIHJlcXVpcmluZyB0 aGUgY2xpZW50IGFuZCBzZXJ2ZXIgdG8gdW5kZXJzdGFuZCB0aGVzZSB2ZW5kb3Itc3BlY2lmaWMg ZXh0ZW5zaW9ucy4gSXQgaXMgZGVzaXJlZCB0aGF0IHNlY3VyaXR5IGNvbmZpZ3VyYXRpb24gaGFz IGEgbmV3IHN0YW5kYXJkaXplZCBvcHRpb24sIHNpbmNlIG1vc3QgcGFyYW1ldGVycyBhcmUgY29t bW9uIGFjcm9zcyBtb3N0IGNsaWVudHMgYW5kIHNlcnZlcnMuCgpUaGFua3MsCllhbmcKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwq3orz+yMs6IFRlZCBMZW1vbiBbVGVk LkxlbW9uQG5vbWludW0uY29tXQq3osvNyrG85DogMjAxMsTqM9TCMjfI1SAyMzoxOQq1vTogQWxw ZXIgWWVnaW47IGRoYyBXRwrW98ziOiBSZTogW2RoY3dnXSBkcmFmdC1iaS1kaGMtc2VjLW9wdGlv bgoKPiBSRkMgMzExOCBpcyBub3QgdXNlZC4gU2VuZGluZyBzZWN1cml0eSBwYXJhbWV0ZXJzIG92 ZXIgREhDUCBuZWVkcyBjb25zaWRlcmF0aW9uLgoKWWVzLCB3ZSBoYXZlIHByZXR0eSBtdWNoIGdp dmVuIHVwIG9uIHByb3ZpZGluZyBpbmZvcm1hdGlvbiBsaWtlIHRoaXMgaW4gREhDUC4gICBJdCBk b2Vzbid0IG1ha2UgYW55IHNlbnNlIHRvIGRvIHNvLCBiZWNhdXNlIERIQ1AgZG9lcyBub3Qgb3Bl cmF0ZSBpbiBjb250cm9sbGVkIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMuICAgRXZlbiBpZiB5b3Ug YXV0aGVudGljYXRlIHRoZSBESENQIHNlcnZlciwgeW91IHN0aWxsIGNhbid0IHRydXN0IGl0IHRv IHRlbGwgeW91IHdoYXQgUEtJIHNlcnZlciB0byB0YWxrIHRvLgoK From list-dhcwg@dragon.net Wed Mar 28 08:54:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B32D21E8294 for ; Wed, 28 Mar 2012 08:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAEXH0X4iQfw for ; Wed, 28 Mar 2012 08:54:31 -0700 (PDT) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id 170B821E816A for ; Wed, 28 Mar 2012 08:54:31 -0700 (PDT) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 48C023740639 for ; Wed, 28 Mar 2012 08:54:30 -0700 (PDT) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id B7FAE693D0A; Wed, 28 Mar 2012 17:54:29 +0200 (CEST) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id B5002693D05 for ; Wed, 28 Mar 2012 17:54:29 +0200 (CEST) To: dhcwg@ietf.org From: Paul Ebersman In-reply-to: References: <20120209.205240.78726629.sthaug@nethelp.no> Comments: In-reply-to Simon Hobson message dated "Thu, 09 Feb 2012 23:28:00 +0000." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Wed, 28 Mar 2012 17:54:29 +0200 Message-Id: <20120328155429.B7FAE693D0A@fafnir.remote.dragon.net> Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:54:31 -0000 Would like to add my support for doing this in the relay. While the fact that there is a cisco patent is not ideal, I think that updating code in relays from the usual suspects (cisco, juniper, isc, etc.) and dhcp servers (isc, microsoft) is much easier and more likely than trying to update client code. Most folks that want this are much more likely to already be running relays, be pretty current on code, etc. That seems to outweigh the hassles of dealing with the existing patent. From Ted.Lemon@nominum.com Wed Mar 28 09:30:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532A921E819E for ; Wed, 28 Mar 2012 09:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WG2kifCiA3S for ; Wed, 28 Mar 2012 09:30:51 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9FA21E8191 for ; Wed, 28 Mar 2012 09:30:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT3M8ux4MXMsnYjDAxUd9lE0unKGAA/1l@postini.com; Wed, 28 Mar 2012 09:30:51 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BC8B41B80D5 for ; Wed, 28 Mar 2012 09:30:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B1074190064; Wed, 28 Mar 2012 09:30:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 28 Mar 2012 09:30:50 -0700 From: Ted Lemon To: Cui Yang , Alper Yegin , dhc WG Thread-Topic: [dhcwg] draft-bi-dhc-sec-option Thread-Index: AQHNDCs97FdY0hE8ekCzaZlLGDHV+ZZ+QWZIgAIPqID//5YZaQ== Date: Wed, 28 Mar 2012 16:30:50 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D1DD6@mbx-01.win.nominum.com> References: , <2F208A97-BFF3-4820-BA98-3E47AC41D992@yegin.org>, <8D23D4052ABE7A4490E77B1A012B6307472C3E6F@mbx-02.win.nominum.com>, <8CC0CB0BCAE52F46882E17828A9AE2161F479B8F@SZXEML508-MBS.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE2161F479B8F@SZXEML508-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] draft-bi-dhc-sec-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:30:52 -0000 > The proposed DHCP option is aimed to help set up the security mechanism, = i.e., carrying IP addresses of PKI server, etc. > But the option itself does not need to be protected, or in other words, t= he security does not necessarily rely on the DHCP option. So if a rogue DHCP server provides a PKI server address, the client will be= able to tell that it is not a legitimate server without revealing sensitiv= e information to it? From cuiyang@huawei.com Wed Mar 28 10:31:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64D921E809E for ; Wed, 28 Mar 2012 10:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg5T30y7SeEb for ; Wed, 28 Mar 2012 10:31:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3A85621E804A for ; Wed, 28 Mar 2012 10:31:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET69298; Wed, 28 Mar 2012 13:31:35 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 10:29:32 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 10:29:36 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 01:29:26 +0800 From: Cui Yang To: Ted Lemon , Alper Yegin , dhc WG Thread-Topic: [dhcwg] draft-bi-dhc-sec-option Thread-Index: AQHNDEv5iTILqwgG4EabUrbxfUEvZ5Z/0S6a//+QYwCAAI3x1A== Date: Wed, 28 Mar 2012 17:29:24 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2161F479BD7@SZXEML508-MBS.china.huawei.com> References: , <2F208A97-BFF3-4820-BA98-3E47AC41D992@yegin.org>, <8D23D4052ABE7A4490E77B1A012B6307472C3E6F@mbx-02.win.nominum.com>, <8CC0CB0BCAE52F46882E17828A9AE2161F479B8F@SZXEML508-MBS.china.huawei.com>, <8D23D4052ABE7A4490E77B1A012B6307472D1DD6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D1DD6@mbx-01.win.nominum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.67] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] draft-bi-dhc-sec-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:31:36 -0000 WWVzLCB0aGUgY2xpZW50IGNvdWxkIGZpbmQgb3V0IHRoYXQgdGhlIFBLSSBzZXJ2ZXIgaXQgaXMg dGFsa2luZyB3aXRoIGlzIG5vdCBhIHZhbGlkIG9uZSBpbiB0aGlzIGNhc2UsIGFmdGVyIHJ1bm5p bmcgYSBtdXR1YWwgYXV0aGVudGljYXRpb24uCkEgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBtZXRob2Qg aW4gWC41MDkgW1JGQzQyMTAsNDIxMV0gY291bGQgYmUgdXNlZCB0byBhdm9pZCByZXZlYWxpbmcg dGhlIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4KCkJSLApZYW5nCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18Kt6K8/sjLOiBUZWQgTGVtb24gW1RlZC5MZW1vbkBub21pbnVt LmNvbV0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjI5yNUgMDozMAq1vTogQ3VpIFlhbmc7IEFscGVyIFll Z2luOyBkaGMgV0cK1vfM4jogUkU6IFtkaGN3Z10gZHJhZnQtYmktZGhjLXNlYy1vcHRpb24KCj4g VGhlIHByb3Bvc2VkIERIQ1Agb3B0aW9uIGlzIGFpbWVkIHRvIGhlbHAgc2V0IHVwIHRoZSBzZWN1 cml0eSBtZWNoYW5pc20sIGkuZS4sIGNhcnJ5aW5nIElQIGFkZHJlc3NlcyBvZiBQS0kgc2VydmVy LCBldGMuCj4gQnV0IHRoZSBvcHRpb24gaXRzZWxmIGRvZXMgbm90IG5lZWQgdG8gYmUgcHJvdGVj dGVkLCBvciBpbiBvdGhlciB3b3JkcywgdGhlIHNlY3VyaXR5IGRvZXMgbm90IG5lY2Vzc2FyaWx5 IHJlbHkgb24gdGhlIERIQ1Agb3B0aW9uLgoKU28gaWYgYSByb2d1ZSBESENQIHNlcnZlciBwcm92 aWRlcyBhIFBLSSBzZXJ2ZXIgYWRkcmVzcywgdGhlIGNsaWVudCB3aWxsIGJlIGFibGUgdG8gdGVs bCB0aGF0IGl0IGlzIG5vdCBhIGxlZ2l0aW1hdGUgc2VydmVyIHdpdGhvdXQgcmV2ZWFsaW5nIHNl bnNpdGl2ZSBpbmZvcm1hdGlvbiB0byBpdD8K From internet-drafts@ietf.org Wed Mar 28 23:40:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E25321E80B5; Wed, 28 Mar 2012 23:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ1nGVaIj8rr; Wed, 28 Mar 2012 23:40:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D49621E80C0; Wed, 28 Mar 2012 23:40:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120329064000.31661.15219.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 23:40:00 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:40:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : DHCPv4 over IPv6 Transport Author(s) : Yong Cui Peng Wu Jianping Wu Ted Lemon Filename : draft-ietf-dhc-dhcpv4-over-ipv6-02.txt Pages : 11 Date : 2012-03-28 In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices using DHCPv4 with an IPv6 transport. It is done by extending DHCP client and server behavior, and by adding a new Relay Agent Information option to carry the IPv6 address of the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-ipv6-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-ipv6-02.txt From jiangsheng@huawei.com Thu Mar 29 01:22:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD4321F86A6 for ; Thu, 29 Mar 2012 01:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QusVqiFtuto6 for ; Thu, 29 Mar 2012 01:22:26 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB8AD21F84F2 for ; Thu, 29 Mar 2012 01:22:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM12766; Thu, 29 Mar 2012 04:22:25 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 01:20:19 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 01:19:32 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 16:19:20 +0800 From: Sheng Jiang To: "dhcwg@ietf.org" Thread-Topic: Review request for draft-ietf-dhc-host-gen-id Thread-Index: AQHNDYTEvKYY7dEar06J4LJG6pajkA== Date: Thu, 29 Mar 2012 08:20:13 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E47C59E@SZXEML506-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [dhcwg] Review request for draft-ietf-dhc-host-gen-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:22:28 -0000 Hi, DHCers, The authors would like to get more reviews for "Prefix Assignment in DHCPv6= " (https://datatracker.ietf.org/doc/draft-ietf-dhc-host-gen-id/). Your comments are really appreciated. Best regards, Sheng= From tomasz.mrugalski@gmail.com Thu Mar 29 02:31:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2AC21F89BD for ; Thu, 29 Mar 2012 02:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUSnk6Gj2xXi for ; Thu, 29 Mar 2012 02:31:29 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1430D21F8A63 for ; Thu, 29 Mar 2012 02:31:28 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1930248bku.31 for ; Thu, 29 Mar 2012 02:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=6TrnvkgPSQhsaeoKwkGoq2zCDZMFGdaOH56a5O5i1YE=; b=DMryxH36iQc36wn4XtqmnHLvpcAbuNxUQz1kZqutb/9LK9YJyeDI4KEUQ6ozSOQ8RP v92cgPE72NUYzCKXKEZn8QICa2KksA/zvpvKhf9BNvBozfAOUdOYWTDzGEYkvHCXt/M6 wEcDswXqC32cvvgCGqsy/aNsWXn1ycw5j0LpQVjnRMRpQDSAXKpeFUDS4crAI2kvoswO /W57ZtphkcFRchvv8cTsNvk7iw3JRlMhOGK7GWGvMOavDnI5I6lYau3Prf0mf9r+iSPJ ibZcvlGARnRw8rIc61VeHWgi3Gt3QN3LIOzwRwf7BUfZDF5Dd0+3BiqeP5xWjvBCtnNE r8Yg== Received: by 10.204.150.86 with SMTP id x22mr13826016bkv.136.1333013487629; Thu, 29 Mar 2012 02:31:27 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id jd17sm12313148bkb.4.2012.03.29.02.31.26 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 02:31:27 -0700 (PDT) Message-ID: <4F742BEE.7040200@gmail.com> Date: Thu, 29 Mar 2012 11:31:26 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: DHC WG X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Helping with draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:31:30 -0000 Hi, I would like to confirm what I stated during DHC meeting. I'm interested in this draft going forward. Ted asked for voluneers to help with this work. I will join this effort once work on DHCPv6 route option is completed. I was also just told that there is one other person, who is interested in joining this effort. I'm not sure how we should proceed with this? Should we contact David and ask him to upload -08 version with new co-author(s)? Or perhaps start new draft based on this, but focused on DHCPv6 only? What happens with the original draft-ietf-dhc-option-guidelines then? Can it be removed somehow from WG item list? Cheers, Tomek Mrugalski From tomasz.mrugalski@gmail.com Thu Mar 29 02:31:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D101221F89BD for ; Thu, 29 Mar 2012 02:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xocpD0iQoeFV for ; Thu, 29 Mar 2012 02:31:57 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1022E21F8A6E for ; Thu, 29 Mar 2012 02:31:56 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id w5so1930248bku.31 for ; Thu, 29 Mar 2012 02:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=N2HgtoW/Oql0gbxJZyIApUsGd8zA9O4JAxYSnXyGVgc=; b=ZqXHkoHDrTCfmhIB3Ji53rdhNHWgx+CP3OJG/wPh/abOdq1sy8qIqKQAzGjtjqVRAB rjZBF4WAI6zRxaehxkesVCYV5NAASW7nIKNekAS+R9yiPzz2achG6niM0Qvmqp9GBEjw 1J2IgvSQnFS5CEi2jULbIsHns5rIk05A/1CP3UrW/EskDwzPSZwlkQN1U9PKWE2/0pEk eD0Hyx63KIfN8uvW3iL0UtNESdEFM/DiJwK08bB1KS2NGCeYbrLLguqxQRH+OEfEmq/z dfziu2bdyxesgo+/kM/WbP7Szvc8Y/ANk4nRv1nDSIFmlit1RxzK06k5HK8RBOTEvcjH fd0Q== Received: by 10.204.156.216 with SMTP id y24mr13603771bkw.60.1333013516737; Thu, 29 Mar 2012 02:31:56 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id c4sm12338700bkh.0.2012.03.29.02.31.54 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 02:31:54 -0700 (PDT) Message-ID: <4F742C09.8000406@gmail.com> Date: Thu, 29 Mar 2012 11:31:53 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: DHC WG X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:31:57 -0000 I do support this draft and its adoption. I will provide more detailed comments later. It is useful and I'm involved in more than one implementation that is potentially interested in implementing this option. I like the changes made between -00 and -01. One notable thing that should be specified is the actual content of the link-layer address used by a client. I think it should be clarified that this is supposed to be link-layer address from the interface that was used to contact the server. Please note that this is slightly different than DUID-LL or DUID-LLT link-layer. DUIDs state that client picks one ll address, generates DUID and sticks to it. For DUIDs it does not have to be the same interface that is used for communication. Think about a client with 5 interfaces. It will use the same DUID over all 5 interfaces, but will use 5 different LINK_ADDR option. Oh, and the draft should be renamed once adopted - it is no longer called hardware option. Something like draft-ietf-dhc-dhcpv6-link-layer-option will do just fine. Tomek From jiangsheng@huawei.com Thu Mar 29 04:26:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D387B21F8974 for ; Thu, 29 Mar 2012 04:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvbmDECNB5my for ; Thu, 29 Mar 2012 04:26:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE021F8812 for ; Thu, 29 Mar 2012 04:26:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM22376; Thu, 29 Mar 2012 07:26:21 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 04:24:45 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 04:24:50 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 19:24:46 +0800 From: Sheng Jiang To: Tomek Mrugalski , DHC WG Thread-Topic: [dhcwg] Helping with draft-ietf-dhc-option-guidelines Thread-Index: AQHNDY7C6W0E12Kxkkys5CpIJAudapaBHz/5 Date: Thu, 29 Mar 2012 11:24:45 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E47C828@SZXEML506-MBS.china.huawei.com> References: <4F742BEE.7040200@gmail.com> In-Reply-To: <4F742BEE.7040200@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Helping with draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:26:22 -0000 Hi, Tomek, As we discussed with Ted after the DHC meeting, we can start either a total= new draft or continue with the current one depending on whether David Hank= ins responses. In either case, I think David has credit to continue to be c= oauthor until he refuses. I will provide a primary version for DHCPv6 optio= n guideline by end of April. Meanwhile, I am not sure whether it is worthy writing a DHCPv4 option guide= line. If the WG or at least WG chairs confirm, we can form a force for it. Best regards, Sheng ________________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf of Tomek Mr= ugalski [tomasz.mrugalski@gmail.com] Sent: 29 March 2012 17:31 To: DHC WG Subject: [dhcwg] Helping with draft-ietf-dhc-option-guidelines Hi, I would like to confirm what I stated during DHC meeting. I'm interested in this draft going forward. Ted asked for voluneers to help with this work. I will join this effort once work on DHCPv6 route option is completed. I was also just told that there is one other person, who is interested in joining this effort. I'm not sure how we should proceed with this? Should we contact David and ask him to upload -08 version with new co-author(s)? Or perhaps start new draft based on this, but focused on DHCPv6 only? What happens with the original draft-ietf-dhc-option-guidelines then? Can it be removed somehow from WG item list? Cheers, Tomek Mrugalski _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg= From Ted.Lemon@nominum.com Thu Mar 29 04:34:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B8D21F8985 for ; Thu, 29 Mar 2012 04:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSi2lO8SxU6K for ; Thu, 29 Mar 2012 04:34:13 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0A63021F88D0 for ; Thu, 29 Mar 2012 04:34:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RIs2oC1AWeZjpYSKjmVHC4BQIUdg9f@postini.com; Thu, 29 Mar 2012 04:34:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 26DE11B81B5 for ; Thu, 29 Mar 2012 04:34:11 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1945C190064; Thu, 29 Mar 2012 04:34:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 04:34:11 -0700 From: Ted Lemon To: Sheng Jiang , Tomek Mrugalski , DHC WG Thread-Topic: [dhcwg] Helping with draft-ietf-dhc-option-guidelines Thread-Index: AQHNDY69IQllAIa1I0aCBhNtguvh/5aBl1GA//+M7h0= Date: Thu, 29 Mar 2012 11:34:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4160@mbx-01.win.nominum.com> References: <4F742BEE.7040200@gmail.com>, <5D36713D8A4E7348A7E10DF7437A4B921E47C828@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E47C828@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Helping with draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:34:17 -0000 The usual way to do this is to clearly acknowledge the original author in t= he acknowledgments section rather than including him as an author. If you= include him as an author, it places requirements on him that aren't approp= riate in this case. From sthaug@nethelp.no Thu Mar 29 04:56:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839C721F89C2 for ; Thu, 29 Mar 2012 04:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-YrlY8przod for ; Thu, 29 Mar 2012 04:56:34 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 88C1F21F89C0 for ; Thu, 29 Mar 2012 04:56:32 -0700 (PDT) Received: (qmail 31464 invoked from network); 29 Mar 2012 11:56:30 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 29 Mar 2012 11:56:30 -0000 Date: Thu, 29 Mar 2012 13:56:30 +0200 (CEST) Message-Id: <20120329.135630.74725067.sthaug@nethelp.no> To: tomasz.mrugalski@gmail.com From: sthaug@nethelp.no In-Reply-To: <4F742C09.8000406@gmail.com> References: <4F742C09.8000406@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:56:34 -0000 > One notable thing that should be specified is the actual content of the > link-layer address used by a client. I think it should be clarified that > this is supposed to be link-layer address from the interface that was > used to contact the server. Agreed. This is vital. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From msiodelski@gmail.com Thu Mar 29 04:51:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B7A21F88AE for ; Thu, 29 Mar 2012 04:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4-zREQXO5VQ for ; Thu, 29 Mar 2012 04:51:40 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E833821F890D for ; Thu, 29 Mar 2012 04:51:39 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1647526vcb.31 for ; Thu, 29 Mar 2012 04:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UMubXisWBB73LLNHKLH7sYu1Ius1BrNX8r0/xfwBrrQ=; b=MLHCTO5k4vksDLjPXLzPx6Cztkwr8toYuvi+3bgbzyMly/wfijei46eK7XGpkNEw3q wnz6PEGhnIlLc86jcxEVMgM2S6ACDqYOB0YByI5wg6ahk7T0tjjEi+cGrVlOi5GH2KzB DKzzR+2G37eGWWzABl+mWjTSkKouZPrie08+6vf7DGiLtXnSHLfDa4OhhXYgR+sucMuh ungXNafooN7OwsBCpevs+c3K6fpivzCt6BGP4FVks16wPdrf1AK8P/406zA1ImGJgLYu fF9APulYpSwzW82aOO6eY7+Gkm8GCvqC/FhfRN9scT1gy43EnTIQcZYPgYbILAO9t2kM SNvA== MIME-Version: 1.0 Received: by 10.52.22.207 with SMTP id g15mr13074829vdf.90.1333021899436; Thu, 29 Mar 2012 04:51:39 -0700 (PDT) Received: by 10.220.4.82 with HTTP; Thu, 29 Mar 2012 04:51:38 -0700 (PDT) Date: Thu, 29 Mar 2012 13:51:38 +0200 Message-ID: From: Marcin Siodelski To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=20cf3071c8bccb319304bc6058ae Subject: Re: [dhcwg] Helping with draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:58:42 -0000 --20cf3071c8bccb319304bc6058ae Content-Type: text/plain; charset=ISO-8859-1 Hi, I like the idea of draft-ietf-dhc-option-guidelines and I volounteer to participate in this effort. Regards, Marcin Siodelski --20cf3071c8bccb319304bc6058ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I like the idea of draft-ietf-dhc-option-guidelines and=A0I=A0volounte= er to participate in this effort.
=A0
Regards,
Marcin Siodelski
--20cf3071c8bccb319304bc6058ae-- From Ted.Lemon@nominum.com Thu Mar 29 05:08:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC0B21F88DC for ; Thu, 29 Mar 2012 05:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4WoEOsR-lVZ for ; Thu, 29 Mar 2012 05:08:30 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 00ECA21F8883 for ; Thu, 29 Mar 2012 05:08:29 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RQvLicqLbLDy083Jk81w+F+8NZnG0F@postini.com; Thu, 29 Mar 2012 05:08:30 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 792361B8069 for ; Thu, 29 Mar 2012 05:08:28 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6D8FF190064; Thu, 29 Mar 2012 05:08:28 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 05:08:28 -0700 From: Ted Lemon To: Marcin Siodelski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Helping with draft-ietf-dhc-option-guidelines Thread-Index: AQHNDaJMIQllAIa1I0aCBhNtguvh/5aBLbkx Date: Thu, 29 Mar 2012 12:08:27 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4234@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Helping with draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:08:32 -0000 > I like the idea of draft-ietf-dhc-option-guidelines and I volounteer to p= articipate in this effort. Okay. Please be in touch with Tomasz and Sheng. Tomasz and Sheng, I hav= e taken documenting existing DHCPv6 option formats off of my to-do list, so= please don't let me down! From Francis.Dupont@fdupont.fr Thu Mar 29 05:34:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185AA21F8AC4 for ; Thu, 29 Mar 2012 05:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li4-RhWxEQ+W for ; Thu, 29 Mar 2012 05:34:01 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 6086621F8ABC for ; Thu, 29 Mar 2012 05:34:01 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2TCXxxP001553; Thu, 29 Mar 2012 14:34:00 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203291234.q2TCXxxP001553@givry.fdupont.fr> From: Francis Dupont To: sthaug@nethelp.no In-reply-to: Your message of Thu, 29 Mar 2012 13:56:30 +0200. <20120329.135630.74725067.sthaug@nethelp.no> Date: Thu, 29 Mar 2012 14:33:59 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:34:02 -0000 In your previous mail you wrote: > > One notable thing that should be specified is the actual content of the > > link-layer address used by a client. I think it should be clarified that > > this is supposed to be link-layer address from the interface that was > > used to contact the server. > > Agreed. This is vital. +1 Regards Francis.Dupont@fdupont.fr PS: one thing which took unexpected time in the SD-NAT demo at the IETF meeting on Sunday was the fact the LL DUID of CPE boxes didn't contain the MAC address of the Ethernet uplink (the one printed on the box, or returned by ifconfig / ip addr) but the previous (value - 1) one... BTW I believe it shouldn't have been too surprising: it is one of the reasons the idea to pickup the MAC address in LL or LLT DUIDs doesn't work. From dankney@network1.net Thu Mar 29 05:39:32 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BC921F8A87 for ; Thu, 29 Mar 2012 05:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq2guQ6QSKlb for ; Thu, 29 Mar 2012 05:39:32 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 254F621F84F8 for ; Thu, 29 Mar 2012 05:39:32 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 3F8E9542B96; Thu, 29 Mar 2012 08:39:30 -0400 (EDT) Date: Thu, 29 Mar 2012 08:39:30 -0400 (EDT) From: perl-list To: Francis Dupont Message-ID: <7e8babbe-d784-4adb-868e-e72389e59781@zimbra.network1.net> In-Reply-To: <201203291234.q2TCXxxP001553@givry.fdupont.fr> Content-Type: multipart/alternative; boundary="=_53aefe4a-0116-482f-8631-d11bfcd0a486" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:39:32 -0000 --=_53aefe4a-0116-482f-8631-d11bfcd0a486 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > ] > > > One notable thing that should be specified is the actual content > > > of the > > > link-layer address used by a client. I think it should be > > > clarified that > > > this is supposed to be link-layer address from the interface that > > > was > > > used to contact the server. > > > > Agreed. This is vital. > +1 I agree with this. --=_53aefe4a-0116-482f-8631-d11bfcd0a486 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
]
>  > One notable thing that should be specified is the actual content of the
>  > link-layer address used by a client. I think it should be clarified that
>  > this is supposed to be link-layer address from the interface that was
>  > used to contact the server.
>  
>  Agreed. This is vital.

+1

I agree with this.
--=_53aefe4a-0116-482f-8631-d11bfcd0a486-- From jiangsheng@huawei.com Thu Mar 29 05:41:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FC621F8AF5 for ; Thu, 29 Mar 2012 05:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYnZx7KqLssy for ; Thu, 29 Mar 2012 05:41:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A725921F8AF2 for ; Thu, 29 Mar 2012 05:41:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU28634; Thu, 29 Mar 2012 08:41:13 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 05:39:42 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 05:39:39 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 20:39:36 +0800 From: Sheng Jiang To: Ted Lemon , Marcin Siodelski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Helping with draft-ietf-dhc-option-guidelines Thread-Index: AQHNDaJM6W0E12Kxkkys5CpIJAudapaAp+qAgACOnw8= Date: Thu, 29 Mar 2012 12:39:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E47CA59@SZXEML506-MBS.china.huawei.com> References: , <8D23D4052ABE7A4490E77B1A012B6307472D4234@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4234@mbx-01.win.nominum.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Helping with draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:41:15 -0000 Hi, Ted, You can count on us. :) Sheng ________________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf of Ted Lemo= n [Ted.Lemon@nominum.com] Sent: 29 March 2012 20:08 To: Marcin Siodelski; dhcwg@ietf.org Subject: Re: [dhcwg] Helping with draft-ietf-dhc-option-guidelines > I like the idea of draft-ietf-dhc-option-guidelines and I volounteer to p= articipate in this effort. Okay. Please be in touch with Tomasz and Sheng. Tomasz and Sheng, I hav= e taken documenting existing DHCPv6 option formats off of my to-do list, so= please don't let me down! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg= From Niall.oReilly@ucd.ie Thu Mar 29 05:43:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5D721F8A77 for ; Thu, 29 Mar 2012 05:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuWvGR8yGFDP for ; Thu, 29 Mar 2012 05:43:14 -0700 (PDT) Received: from mx4.ucd.ie (angel.ucd.ie [137.43.231.112]) by ietfa.amsl.com (Postfix) with ESMTP id A2F3621F8A71 for ; Thu, 29 Mar 2012 05:43:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,337,1330905600"; d="scan'208";a="11835140" Received: from dhcp-c101a8a5.ucd.ie ([193.1.168.165]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 29 Mar 2012 13:43:07 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Niall O'Reilly In-Reply-To: <201203291234.q2TCXxxP001553@givry.fdupont.fr> Date: Thu, 29 Mar 2012 13:43:06 +0100 Content-Transfer-Encoding: 7bit Message-Id: <48648AC3-192C-48A7-A969-72C326266716@ucd.ie> References: <201203291234.q2TCXxxP001553@givry.fdupont.fr> To: dhcwg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [dhcwg] Comments on draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:43:14 -0000 On 29 Mar 2012, at 13:33, Francis Dupont wrote: >>> >>> One notable thing that should be specified is the actual content of the >>> link-layer address used by a client. I think it should be clarified that >>> this is supposed to be link-layer address from the interface that was >>> used to contact the server. >> >> Agreed. This is vital. > > +1 Me too. From Ted.Lemon@nominum.com Thu Mar 29 05:56:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AE421F8AFD for ; Thu, 29 Mar 2012 05:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdw554zVU+Fe for ; Thu, 29 Mar 2012 05:56:35 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id AB33E21F8AFB for ; Thu, 29 Mar 2012 05:56:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RcAt7fRDMF5pDmjcRVx9Dyh6ZZBazr@postini.com; Thu, 29 Mar 2012 05:56:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9C45D1B81E9 for ; Thu, 29 Mar 2012 05:56:33 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 94D49190064; Thu, 29 Mar 2012 05:56:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 05:56:28 -0700 From: Ted Lemon To: Niall O'Reilly , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Comments on draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 Thread-Index: AQHNDamH8zNVPUzjtUu+B3tDt5N8ZJaBOt+d Date: Thu, 29 Mar 2012 12:56:27 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D432B@mbx-01.win.nominum.com> References: <201203291234.q2TCXxxP001553@givry.fdupont.fr>, <48648AC3-192C-48A7-A969-72C326266716@ucd.ie> In-Reply-To: <48648AC3-192C-48A7-A969-72C326266716@ucd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Comments on draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:56:35 -0000 Point of order, I love to see people participate, but the time to send your= +1 messages is when we do calls for adoption (which we will be doing a lot= of soon) and when we do last calls (which, again, we will be doing a fair = number of soon). It's also good to get a sense of consensus when there is= disagreement about something. But if everyone agrees, there's no need to= chime in with an . :) From alexandru.petrescu@gmail.com Thu Mar 29 06:49:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B513621F8AD7 for ; Thu, 29 Mar 2012 06:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBbHtkxMuMG0 for ; Thu, 29 Mar 2012 06:49:20 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 12E8921F8A3F for ; Thu, 29 Mar 2012 06:49:19 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so65157wib.13 for ; Thu, 29 Mar 2012 06:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/ifunnZDZ6jgF5Ygb45pslblQ5SRte2SFa7z7WwiumU=; b=ItzMqxOJWB3rKIAIH73cVnEZetwUVrwv6JdY1lFGTkr1rcjyWTI1W6uKe8PjG3LgQs Ozf/jEzMJpIVXDjGEulMlVGh9rIvmZ2kZuemTFgHhsyYrBFQ3OhlT7UOQiVTdHJ2R+FG jIojgatKlHG3zRe7rJrxYw2Caq0y69A1W/gG/qlTeiyuFJkKT3Xa+bIkNSLyKAFTskmE LYd+7rdplySke42MvqD66QOX8RiuHVDZ6tCoN8al8/XZmWAFWKapVa4RmBzFVsWX++2h RFoaNbHUU3GBJMpv/QQuHgaC8QG4l/oV5MFvyiXFHR24ejs2L8hjvFShQibjx6S+l/Xj rqOA== Received: by 10.180.79.72 with SMTP id h8mr5942917wix.1.1333028959303; Thu, 29 Mar 2012 06:49:19 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id j3sm29079110wiw.1.2012.03.29.06.49.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 06:49:18 -0700 (PDT) Message-ID: <4F746855.8050006@gmail.com> Date: Thu, 29 Mar 2012 15:49:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B921E47C59E@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E47C59E@SZXEML506-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Review request for draft-ietf-dhc-host-gen-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:49:21 -0000 Could the value of the prefix-len field of IA_PD of RFC3633 used by this draft as "IA_PA" be larger than 64? If not it should say so, and eventually encoding on 6bit instead of 8, maybe. Alex Le 29/03/2012 10:20, Sheng Jiang a écrit : > Hi, DHCers, > > The authors would like to get more reviews for "Prefix Assignment in > DHCPv6" > (https://datatracker.ietf.org/doc/draft-ietf-dhc-host-gen-id/). > > Your comments are really appreciated. > > Best regards, > > Sheng _______________________________________________ dhcwg mailing > list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Thu Mar 29 06:53:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5C21F8B53 for ; Thu, 29 Mar 2012 06:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5ZhpTzl-yij for ; Thu, 29 Mar 2012 06:53:07 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0514321F8938 for ; Thu, 29 Mar 2012 06:53:06 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RpQlydIYnnA6/unR65qtz1MydKjjZd@postini.com; Thu, 29 Mar 2012 06:53:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0E7A81B819B for ; Thu, 29 Mar 2012 06:53:06 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 037A3190064; Thu, 29 Mar 2012 06:53:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 06:53:06 -0700 From: Ted Lemon To: Alexandru Petrescu , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Review request for draft-ietf-dhc-host-gen-id Thread-Index: AQHNDYTEvKYY7dEar06J4LJG6pajkJaBv72A//+Lmtg= Date: Thu, 29 Mar 2012 13:53:06 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D43BA@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B921E47C59E@SZXEML506-MBS.china.huawei.com>, <4F746855.8050006@gmail.com> In-Reply-To: <4F746855.8050006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Review request for draft-ietf-dhc-host-gen-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:53:08 -0000 > If not it should say so, and eventually encoding on 6bit instead of 8, > maybe. DHCP doesn't do bitfields. However, I think that the width of the prefix = is _always_ 64, so maybe we don't need to include a length at all? From greg.rabil@jagornet.com Thu Mar 29 07:11:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6157721E8092 for ; Thu, 29 Mar 2012 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.214 X-Spam-Level: X-Spam-Status: No, score=-1.214 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE0SoqiNeUTv for ; Thu, 29 Mar 2012 07:11:16 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA0DA21E80E4 for ; Thu, 29 Mar 2012 07:11:12 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2221482bku.31 for ; Thu, 29 Mar 2012 07:11:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=TYiU0mjko6X4Q6rfRfXVI/5E8j99pkq4Iot4M+4u5xM=; b=X4AiLNmKl+2gQzhkW8fdTiwgSiYeqYC3XObjIlxKb0cSNQXhqQAbNke39SWlzQqpty xydaOoW2Ow4Wi12CorBxpCkOFvuNaLP4bvUhOSjy0wmJsHmAA9ZX6JLjioBxNxpvLUl7 jLnoWqH4KWj/8L0HbTWU+Bhd3Pu9NTefoxNvFZYs4Y5tB6PubUjS9oZ0iGlLwGlVqyYe JvHqJnJ9vtjLVg+xUpOHLqm7pIZRXBCAJK851GkG9HRDNYwlpSEFvgYk1r9OI0w8AIJe KnqsyptuLzkJT6cUzmTn0j9r6oYx9AYEmjqpkakaH9x6JzGbCe4Kg+38FXAUVnP3PZCa reRg== MIME-Version: 1.0 Received: by 10.204.156.2 with SMTP id u2mr14003534bkw.101.1333030271911; Thu, 29 Mar 2012 07:11:11 -0700 (PDT) Received: by 10.205.42.3 with HTTP; Thu, 29 Mar 2012 07:11:11 -0700 (PDT) Date: Thu, 29 Mar 2012 10:11:11 -0400 Message-ID: From: "A. Gregory Rabil" To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=0015175cd44ad5081704bc624b85 X-Gm-Message-State: ALoCoQkIKLZeh/itYcNTEdD+vdY3qSJAoJ+mTtfnUEAyzHm5h/Z7Kj5QGhfQJi+fSotKqPOlKkLQ Subject: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:11:17 -0000 --0015175cd44ad5081704bc624b85 Content-Type: text/plain; charset=ISO-8859-1 Hello DHC WG, I am looking for clarification around the IAID. Some of this stems from the several discussions recently regarding the DUID and the lack of a MAC address in DHCPv6. Ted (don't mean to call you out here, but it is prevalent to my question) wrote this on the ISC DHCP list: >DUID+IAID uniquely identifies the interface; DUID uniquely identifies the host. My question is can this be guaranteed? From RFC 3315: Identity association (IA) A collection of addresses assigned to a client. Each IA has an associated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces. It states "for example, one for each of its interfaces". So, I don't see this as a MUST, or am I missing something? If the IAID is intended to identify the interface, then I wonder why that is not just the MAC address. If that were the case, then every request would contain the DUID identifying the device, and the IAID to identify the actual interface in which the request was made. I guess my concern is that if we start putting the MAC address in the DHCPv6 packet (which I am in favor of), then we should be sure to specify how it does or does not relate to the IAID. Regards, Greg Rabil --0015175cd44ad5081704bc624b85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello DHC WG,
I am looking for clarification around the IAID. =A0Some o= f this stems from the several discussions recently regarding the DUID and t= he lack of a MAC address in DHCPv6.

Ted (don't= mean to call you out here, but it is prevalent to my question) wrote this = on the ISC DHCP list:

>DUID+IAID uniquely identifies the interf= ace; DUID uniquely identifies the host.

My que= stion is can this be guaranteed? =A0From RFC 3315:

      Identity=
 association (IA) A collection of addresses assigned to
                                a client.  Each IA has an associated
                                IAID.  A client may have more than one
                                IA assigned to it; for example, one for
                                each of its interfaces.
It states "for example, one for each of its interfaces". = =A0So, I don't see this as a MUST, or am I missing something?

If the IAID is intended to identify the interface, t= hen I wonder why that is not just the MAC address. =A0If that were the case= , then every request would contain the DUID identifying the device, and the= IAID to identify the actual interface in which the request was made. =A0I = guess my concern is that if we start putting the MAC address in the DHCPv6 = packet (which I am in favor of), then we should be sure to specify how it d= oes or does not relate to the IAID.

Regards,

Greg Rabil<= /p>

--0015175cd44ad5081704bc624b85-- From greg.rabil@jagornet.com Thu Mar 29 07:18:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF25A21E8163 for ; Thu, 29 Mar 2012 07:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YVG9THfJ84Q for ; Thu, 29 Mar 2012 07:18:15 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D61FF21E8124 for ; Thu, 29 Mar 2012 07:18:14 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2229872bku.31 for ; Thu, 29 Mar 2012 07:18:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=RyhnXSi085rH9lzaL0jjhdS8nn9+4ACBjiB4wZw+Gi8=; b=PpzMXodDwxxk9DsOlKV0PswDO9uKmsw1fBPDFdc5d40e2Pe8WUsvKD+ImeCzs/sf3V 25DtE9kFjavAjdrkLVDbHRryjiqQKLP5GKBoHbBe4/0EAg1duSw1yg7pr+pELEHGsq4N kqm0Qh1BvcZJVx9SjAyu51tTiLS2J/pkhhvI8cTv20WNisXxpHynAmE1dJ/LqiLi9YKH wX+cyCCRUTxFWNdQ6PHZDBUUECrwe1rM+dhOnXoAosDX16ExLxqfpJA4w/yd15nSkeoS 0zTEkZq+ebaepCWzYfOKAnMBqaQqa3qBaOWElevCTo8Kx4CXIU8xYeCSaPzTlNCxShqH 0lTA== MIME-Version: 1.0 Received: by 10.204.152.156 with SMTP id g28mr14262632bkw.83.1333030693648; Thu, 29 Mar 2012 07:18:13 -0700 (PDT) Received: by 10.205.42.3 with HTTP; Thu, 29 Mar 2012 07:18:13 -0700 (PDT) Date: Thu, 29 Mar 2012 10:18:13 -0400 Message-ID: From: "A. Gregory Rabil" To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=0015175cfa30f83bc704bc6264e0 X-Gm-Message-State: ALoCoQn/q3hmJhK6q/EAHieC/j6LKEnPaYVtvqZ5XsYQBGH0QmBMEzF4p0bPwLYwSVgXDk533W70 Subject: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:18:16 -0000 --0015175cfa30f83bc704bc6264e0 Content-Type: text/plain; charset=ISO-8859-1 Sorry, forgot to put a subject line... On Thu, Mar 29, 2012 at 10:11 AM, A. Gregory Rabil wrote: > Hello DHC WG, > I am looking for clarification around the IAID. Some of this stems from > the several discussions recently regarding the DUID and the lack of a MAC > address in DHCPv6. > > Ted (don't mean to call you out here, but it is prevalent to my question) > wrote this on the ISC DHCP list: > > >DUID+IAID uniquely identifies the interface; DUID uniquely identifies the > host. > > My question is can this be guaranteed? From RFC 3315: > > Identity association (IA) A collection of addresses assigned to > a client. Each IA has an associated > IAID. A client may have more than one > IA assigned to it; for example, one for > each of its interfaces. > > It states "for example, one for each of its interfaces". So, I don't see > this as a MUST, or am I missing something? > > If the IAID is intended to identify the interface, then I wonder why that > is not just the MAC address. If that were the case, then every request > would contain the DUID identifying the device, and the IAID to identify the > actual interface in which the request was made. I guess my concern is that > if we start putting the MAC address in the DHCPv6 packet (which I am in > favor of), then we should be sure to specify how it does or does not relate > to the IAID. > > Regards, > > Greg Rabil > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --0015175cfa30f83bc704bc6264e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, forgot to put a subject line...

On= Thu, Mar 29, 2012 at 10:11 AM, A. Gregory Rabil <greg.rabil@jagornet.com> wrote:
Hello DHC WG,
I am looking for clarifica= tion around the IAID. =A0Some of this stems from the several discussions re= cently regarding the DUID and the lack of a MAC address in DHCPv6.

Ted (don't mean to call you out here, but it is pre= valent to my question) wrote this on the ISC DHCP list:

>DUID+IAID uniquely identifies the interface; DUID uniquely iden= tifies the host.

My question is can this be guaranteed? =A0From RFC 3= 315:

      Identity=
 association (IA) A collection of addresses assigned to
                                a client.  Each IA has an associated
                                IAID.  A client may have more than one
                                IA assigned to it; for example, one for
                                each of its interfaces.
It states "for example, one for each of its interfaces". = =A0So, I don't see this as a MUST, or am I missing something?

= If the IAID is intended to identify the interface, then I wonder why that i= s not just the MAC address. =A0If that were the case, then every request wo= uld contain the DUID identifying the device, and the IAID to identify the a= ctual interface in which the request was made. =A0I guess my concern is tha= t if we start putting the MAC address in the DHCPv6 packet (which I am in f= avor of), then we should be sure to specify how it does or does not relate = to the IAID.

Regards,

Greg Rabil



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


--0015175cfa30f83bc704bc6264e0-- From tomasz.mrugalski@gmail.com Thu Mar 29 07:29:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E2E21E80BF for ; Thu, 29 Mar 2012 07:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPKhzrnfVrTn for ; Thu, 29 Mar 2012 07:29:35 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFC7D21E803C for ; Thu, 29 Mar 2012 07:29:34 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2242493bku.31 for ; Thu, 29 Mar 2012 07:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=xwO8Pr6Ie3H2EKy0miPgQQ6dNMvbZxI71Jy6cHHqVXs=; b=fdN2q9zcNr9BcmQHE3CJhX7JICoRQZBktOXcMMqxVLoPq5LR92Wu8NJJj8SZrDNwrb 5sCKVgCXajtDxFeqnLsSB7Xq6svOkbg5hVvezFXSOH5MVAOG9LV6XUj8GGqEYZ+j8zAW E+wWkuejrsao21P8FaW8e9YM3qAcw3nPrpbTv/WmkEoSyOS5CQBJQ9Vj6DFC7hCKR8FL t9UFHHLiZ0I2Rs/80GoyvtO3GAxL9m+GxrL1DwNxWhvTamdEcsKHCLQ9OHn/6XDqOVhM jMW36OCuHivAIenvV5/2lVMxurSgCFxy7/+59k0alCuAuK4QOQgpzFDTWWDUbq1/kYLM DQ/w== Received: by 10.204.154.66 with SMTP id n2mr14375284bkw.77.1333031373497; Thu, 29 Mar 2012 07:29:33 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id t17sm14163261bke.6.2012.03.29.07.29.32 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 07:29:32 -0700 (PDT) Message-ID: <4F7471CA.9010002@gmail.com> Date: Thu, 29 Mar 2012 16:29:30 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ted Lemon References: <4F742BEE.7040200@gmail.com>, <5D36713D8A4E7348A7E10DF7437A4B921E47C828@SZXEML506-MBS.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307472D4160@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4160@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DHC WG Subject: Re: [dhcwg] Helping with draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:29:36 -0000 On 12-03-29 13:34, Ted Lemon wrote: > The usual way to do this is to clearly acknowledge the original > author in the acknowledgments section rather than including him as an > author. If you include him as an author, it places requirements on > him that aren't appropriate in this case. David did a lot of work on this draft and I expect that significant part of new version of this draft (whatever if it is option-guidelines-08 or a completely new draft) will be based on what is in option-guidelines-07. From that perspective, it would be rather inappropriate to remove David. I think it is fair to ask David if he prefers to be kept as co-author or rather be only mentioned in acknowledgements. We will communicate with David off-the list and see what way forward he prefers. Tomek From Francis.Dupont@fdupont.fr Thu Mar 29 07:34:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04F621E8167 for ; Thu, 29 Mar 2012 07:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRVpUQg+gyx4 for ; Thu, 29 Mar 2012 07:34:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4821E8147 for ; Thu, 29 Mar 2012 07:34:20 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2TEYIND011493; Thu, 29 Mar 2012 16:34:18 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203291434.q2TEYIND011493@givry.fdupont.fr> From: Francis Dupont To: "A. Gregory Rabil" In-reply-to: Your message of Thu, 29 Mar 2012 10:18:13 EDT. Date: Thu, 29 Mar 2012 16:34:18 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:34:22 -0000 In your previous mail you wrote: > > >DUID+IAID uniquely identifies the interface; DUID uniquely identifies the > > host. > > > > My question is can this be guaranteed? From RFC 3315: => it is not specified as 1 - 1 relationship: what doesn't make sense is to use the same DUID+IAID for different interfaces, not the opposite. Regards Francis.Dupont@fdupont.fr PS: the hardware address option stuff is very different: the only idea is to match DHCPv4 and DHCPv6 policies on hosts. BTW I think it is not neutral to suggest to add it by relays vs by clients as one trusts less clients than relays... From Ted.Lemon@nominum.com Thu Mar 29 07:41:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61D121F88EA for ; Thu, 29 Mar 2012 07:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.193 X-Spam-Level: X-Spam-Status: No, score=-106.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcRlKi1YsvKL for ; Thu, 29 Mar 2012 07:41:37 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 30B7421F88C7 for ; Thu, 29 Mar 2012 07:41:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT3R0oIqbKRzEevaFJPwy25U34n9R+De4@postini.com; Thu, 29 Mar 2012 07:41:37 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 315621B819B for ; Thu, 29 Mar 2012 07:41:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 28F86190064; Thu, 29 Mar 2012 07:41:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 07:41:36 -0700 From: Ted Lemon To: "A. Gregory Rabil" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] DUID+IAID Thread-Index: AQHNDbbP4FgtkXLiwESgwgUDJGkpD5aBV/Go Date: Thu, 29 Mar 2012 14:41:34 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:41:38 -0000 > Ted (don't mean to call you out here, but it is prevalent to my question)= wrote this on the ISC DHCP list: >>DUID+IAID uniquely identifies the interface; DUID uniquely identifies the= host. > My question is can this be guaranteed? No, I was oversimplifying. The intent was that there might well be more t= han one IAID per interface. In practice, I would expect an IA_NA and an I= A_TA to use different IAIDs, for instance. Similarly for IA_PD. It was = also intended that the client could ask for more than one set of IA_NA addr= esses per interface if it wanted to present more than one identity to the n= etwork. Even if what I'd said weren't an oversimplification, it wouldn't work to us= e the MAC address as the IAID, because it's unnecessarily big. I expect i= t to be rare that a single DHCP request will require 2^48 IAs. From akostur@incognito.com Thu Mar 29 08:32:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C6B21E813B for ; Thu, 29 Mar 2012 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.689 X-Spam-Level: X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpLDl2vgPPEF for ; Thu, 29 Mar 2012 08:32:39 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id CE8AE21E8133 for ; Thu, 29 Mar 2012 08:32:38 -0700 (PDT) Received: from mail-lpp01m010-f46.google.com ([209.85.215.46]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKT3SAlf3aSTE2YccNZBzI9+pHL3Hc52fG@postini.com; Thu, 29 Mar 2012 08:32:39 PDT Received: by mail-lpp01m010-f46.google.com with SMTP id j13so3997643lah.33 for ; Thu, 29 Mar 2012 08:32:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ktgfRPOAkY3PgtJkuR+tQ+pVDp9NcOsewUKcu41EGkQ=; b=ReU5o5TSAOklRnwps/FwPlMvJ49QgtgeAiU9OBa8Tsxp/lsNfspPbsLsq+xiLYo6oo 7JuMoOZCaqWoQ8e1j5kXwyOmPtaqh/dYTavh/2Jh4t0P5vpIP2CxDlUq+Du3wNjUlef4 R/jldX+RPx6zvo3gPFjQSwnqxmitAcMFwlflMlxjPlLj0mlwDgIAevJxA44nyyBclWAV ksB0XQx0Dd10MbAczKhll8KoM1G1yoA0nBMTEnQ5boRBu8LD+Vn6aEgS/anMXLmX7ECx h82PjfbT9/s+ziIb/hEQhv8Alqoe++YpFr85Ukm+03z+kIUHmhCzHinGGlJLEq6Nb/8o 6c8g== MIME-Version: 1.0 Received: by 10.152.145.131 with SMTP id su3mr28108705lab.46.1333035157045; Thu, 29 Mar 2012 08:32:37 -0700 (PDT) Received: by 10.112.86.135 with HTTP; Thu, 29 Mar 2012 08:32:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Mar 2012 08:32:36 -0700 Message-ID: From: Andre Kostur To: "A. Gregory Rabil" Content-Type: multipart/alternative; boundary=e89a8f234ab50240d404bc636fc2 X-Gm-Message-State: ALoCoQkbaAe4A2r/89Pjf9oyYygxOHnwn7Z8yoW8esTqlS6WqC6+RV5sTFOSM38lABLH+63FFBAN Cc: dhcwg@ietf.org Subject: Re: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:32:40 -0000 --e89a8f234ab50240d404bc636fc2 Content-Type: text/plain; charset=ISO-8859-1 Theoretically a device may have different "contexts" on the same interface. So there may be multiple IAIDs on the same interface. The IAID is not intended to specifically identify an interface. On Thu, Mar 29, 2012 at 07:11, A. Gregory Rabil wrote: > Hello DHC WG, > I am looking for clarification around the IAID. Some of this stems from > the several discussions recently regarding the DUID and the lack of a MAC > address in DHCPv6. > > Ted (don't mean to call you out here, but it is prevalent to my question) > wrote this on the ISC DHCP list: > > >DUID+IAID uniquely identifies the interface; DUID uniquely identifies the > host. > > My question is can this be guaranteed? From RFC 3315: > > Identity association (IA) A collection of addresses assigned to > a client. Each IA has an associated > IAID. A client may have more than one > IA assigned to it; for example, one for > each of its interfaces. > > It states "for example, one for each of its interfaces". So, I don't see > this as a MUST, or am I missing something? > > If the IAID is intended to identify the interface, then I wonder why that > is not just the MAC address. If that were the case, then every request > would contain the DUID identifying the device, and the IAID to identify the > actual interface in which the request was made. I guess my concern is that > if we start putting the MAC address in the DHCPv6 packet (which I am in > favor of), then we should be sure to specify how it does or does not relate > to the IAID. > > Regards, > > Greg Rabil > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > -- *Andre Kostur * --e89a8f234ab50240d404bc636fc2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Theoretically a device may have different "contexts&q= uot; on the same interface. =A0So there may be multiple IAIDs on the same i= nterface. =A0The IAID is not intended to specifically identify an interface= .

On Thu, Mar 29, 2012 at 07:11, A. Gregory Ra= bil <greg.r= abil@jagornet.com> wrote:
Hello DHC WG,
I am looking for clarification around the IAID. =A0Some o= f this stems from the several discussions recently regarding the DUID and t= he lack of a MAC address in DHCPv6.

Ted (don't= mean to call you out here, but it is prevalent to my question) wrote this = on the ISC DHCP list:

>DUID+IAID uniquely identifies the interface; DUID uniquely iden= tifies the host.

My question is can this be guaranteed? =A0From RFC 3= 315:

      Identity=
 association (IA) A collection of addresses assigned to
                                a client.  Each IA has an associated
                                IAID.  A client may have more than one
                                IA assigned to it; for example, one for
                                each of its interfaces.
It states "for example, one for each of its interfaces". = =A0So, I don't see this as a MUST, or am I missing something?

= If the IAID is intended to identify the interface, then I wonder why that i= s not just the MAC address. =A0If that were the case, then every request wo= uld contain the DUID identifying the device, and the IAID to identify the a= ctual interface in which the request was made. =A0I guess my concern is tha= t if we start putting the MAC address in the DHCPv6 packet (which I am in f= avor of), then we should be sure to specify how it does or does not relate = to the IAID.

Regards,

Greg Rabil



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--
<= tbody>
Andre Kostur= =A0=A0

--e89a8f234ab50240d404bc636fc2-- From volz@cisco.com Thu Mar 29 09:37:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9CF21F84F7 for ; Thu, 29 Mar 2012 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.11 X-Spam-Level: X-Spam-Status: No, score=-8.11 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9TiuWZsxFHe for ; Thu, 29 Mar 2012 09:37:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A2AE821F84FB for ; Thu, 29 Mar 2012 09:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=5979; q=dns/txt; s=iport; t=1333039039; x=1334248639; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=Xu5rsBVVIs05DpkKmL3yDGi307MZ+NG1KGYEvhw4n2o=; b=Og/MYvAZ0T4aVLeZf7fKtW9z3EVyu7+ay2xO49OUP0Mf2QrCs6pKyVrb vpnTsphXBIKN1Y34FiK/LXM2yBWCMJH1/GdAwZXXigOrZyEC1G4NqXZNw 8/0HVM4c5uvB65MxJe0o0e0hMB0WOxE8EnlSRa4szmjC51dzajOgiHF6k 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEJAFmPdE+tJXG8/2dsb2JhbAA7AQmCRoJ9s04CgQeCCQEBAQMBAQEBDwEQSwsFCwIBCA4KKgICJzABAQQRAiKHYwULnAiNCJIdBIpzAYUTNWMEiCWNPI5GgWiDAyI X-IronPort-AV: E=Sophos;i="4.73,669,1325462400"; d="scan'208,217";a="70502269" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 29 Mar 2012 16:37:19 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2TGbJTa022317; Thu, 29 Mar 2012 16:37:19 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 11:37:18 -0500 Received: from 72.163.62.136 ([72.163.62.136]) by XMB-RCD-101.cisco.com ([72.163.62.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Mar 2012 16:37:18 +0000 References: Content-Transfer-Encoding: 7bit From: "Bernie Volz (volz)" Thread-Topic: [dhcwg] (no subject) Thread-Index: Ac0NyjSyhwmjkWNwSIK8XmUFx3iwGQ== Content-Type: multipart/alternative; boundary="Apple-Mail-28E4F5CC-BEC8-4ED8-9967-446E3A40D291"; charset="iso-8859-1" In-Reply-To: Message-ID: <579EE843-2D7C-40BF-9B94-1777724F0B8E@cisco.com> Date: Thu, 29 Mar 2012 12:37:18 -0400 To: "Andre Kostur" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 29 Mar 2012 16:37:18.0962 (UTC) FILETIME=[35227D20:01CD0DCA] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:37:41 -0000 --Apple-Mail-28E4F5CC-BEC8-4ED8-9967-446E3A40D291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Two interfaces MUST use different IAIDs, but two IAIDs need not be on differ= ent interfaces. Sent from my iPad On Mar 29, 2012, at 11:32 AM, "Andre Kostur" wrote: > Theoretically a device may have different "contexts" on the same interface= . So there may be multiple IAIDs on the same interface. The IAID is not in= tended to specifically identify an interface. >=20 > On Thu, Mar 29, 2012 at 07:11, A. Gregory Rabil w= rote: > Hello DHC WG, > I am looking for clarification around the IAID. Some of this stems from t= he several discussions recently regarding the DUID and the lack of a MAC add= ress in DHCPv6. >=20 > Ted (don't mean to call you out here, but it is prevalent to my question) w= rote this on the ISC DHCP list: > >DUID+IAID uniquely identifies the interface; DUID uniquely identifies the= host. >=20 > My question is can this be guaranteed? =46rom RFC 3315: >=20 > Identity association (IA) A collection of addresses assigned to > a client. Each IA has an associated > IAID. A client may have more than one > IA assigned to it; for example, one for > each of its interfaces. > It states "for example, one for each of its interfaces". So, I don't see t= his as a MUST, or am I missing something? > If the IAID is intended to identify the interface, then I wonder why that i= s not just the MAC address. If that were the case, then every request would= contain the DUID identifying the device, and the IAID to identify the actua= l interface in which the request was made. I guess my concern is that if we= start putting the MAC address in the DHCPv6 packet (which I am in favor of)= , then we should be sure to specify how it does or does not relate to the IA= ID. >=20 > Regards, >=20 > Greg Rabil >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 >=20 >=20 > --=20 > Andre Kostur =20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-28E4F5CC-BEC8-4ED8-9967-446E3A40D291 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Two interfaces MUST use different IAIDs, but two IAIDs need not be on different interfaces.

Sent from my iPad

On Mar 29, 2012, at 11:32 AM, "Andre Kostur" <akostur@incognito.com> wrote:

Theoretically a device may have different "contexts" on the same interface.  So there may be multiple IAIDs on the same interface.  The IAID is not intended to specifically identify an interface.

On Thu, Mar 29, 2012 at 07:11, A. Gregory Rabil <greg.rabil@jagornet.com> wrote:
Hello DHC WG,
I am looking for clarification around the IAID.  Some of this stems from the several discussions recently regarding the DUID and the lack of a MAC address in DHCPv6.

Ted (don't mean to call you out here, but it is prevalent to my question) wrote this on the ISC DHCP list:

>DUID+IAID uniquely identifies the interface; DUID uniquely identifies the host.

My question is can this be guaranteed?  From RFC 3315:

      Identity association (IA) A collection of addresses assigned to
                                a client.  Each IA has an associated
                                IAID.  A client may have more than one
                                IA assigned to it; for example, one for
                                each of its interfaces.
It states "for example, one for each of its interfaces".  So, I don't see this as a MUST, or am I missing something?

If the IAID is intended to identify the interface, then I wonder why that is not just the MAC address.  If that were the case, then every request would contain the DUID identifying the device, and the IAID to identify the actual interface in which the request was made.  I guess my concern is that if we start putting the MAC address in the DHCPv6 packet (which I am in favor of), then we should be sure to specify how it does or does not relate to the IAID.

Regards,

Greg Rabil



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg




--
Andre Kostur  

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
--Apple-Mail-28E4F5CC-BEC8-4ED8-9967-446E3A40D291-- From greg.rabil@jagornet.com Thu Mar 29 10:06:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0523D21E80F6 for ; Thu, 29 Mar 2012 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIoscoYMvafH for ; Thu, 29 Mar 2012 10:06:21 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8917921E80F0 for ; Thu, 29 Mar 2012 10:06:20 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2419924bku.31 for ; Thu, 29 Mar 2012 10:06:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=r/xtTwp01tINv02l2dZsyN8V95kZ2OftLrTqhwM4jSM=; b=lSKNk1dpEQPlYOsG/VNSWI8CF6tmBnAmxXoDM1tZAfvQ1W3y26o2pY94usGU6gkJ7m kkzcoHvB1y0eS9Bb5pBGFL2Fgu4unzS9ddDVKnnF63XL+jpaSCxbH9gi/I82WRAHDTcL 0RP2+mqnRQfQTXlKrml65qB7oCSenmIQXclmm4luVeWm0Qzkj3tsanY4FxR5UTx7ay1/ FopdjDwnjk+2QR15GRG7Jq0NffVBCM599ubTk9KAgd+r8nwde88gZVBVoyuoolPAcfU8 XPtZ0O3UMr9Kuch41cLRHMaRY1bsheDhWm+rESFkUnZbH++veQWC0SNljJ5Exi/ref4a uhqQ== MIME-Version: 1.0 Received: by 10.204.154.202 with SMTP id p10mr13741605bkw.79.1333040779327; Thu, 29 Mar 2012 10:06:19 -0700 (PDT) Received: by 10.204.98.198 with HTTP; Thu, 29 Mar 2012 10:06:19 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com> Date: Thu, 29 Mar 2012 13:06:19 -0400 Message-ID: From: "A. Gregory Rabil" To: "dhcwg@ietf.org" Content-Type: multipart/alternative; boundary=0015175d07bc1f7b9f04bc64bea2 X-Gm-Message-State: ALoCoQnMA8F0ghmCaYB9GMUTj0B/Q/Uxg9S53DEcc3pxVd0QJoE0ypMKi+tDSqrofsE8qyURxcF9 Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:06:22 -0000 --0015175d07bc1f7b9f04bc64bea2 Content-Type: text/plain; charset=ISO-8859-1 Thanks Ted. > The intent was that there might well be more than one IAID per interface. > In practice, I would expect an IA_NA and an IA_TA to use different IAIDs, for instance. Similarly for IA_PD. RFC 3315 states this: The IAID number space for the IA_TA option IAID number space is separate from the IA_NA option IAID number space. Based on that statement, I was thinking that a typical implementation might use the index of an interface as the IAID. For example, eth0=IAID1. Then, if an IA_NA, IA_TA, or IA_PD sent on eth0, would all use IAID=1, and are distinguished by IA_TYPE as described in the text above. However, that obviously would not work if there are more than one IA of the same type on that interface, as you described: > It was also intended that the client could ask for more than one set of IA_NA addresses per interface if it wanted to present more than one identity to the network. Yes, and I believe this is further clarified in RFC 3315 with this text: A client must associate at least one distinct IA with each of its network interfaces for which it is to request the assignment of IPv6 addresses from a DHCP server. The client uses the IAs assigned to an interface to obtain configuration information from a server for that interface. Each IA must be associated with exactly one interface. So, each IA is associated with exactly one interface, but not necessarily the other way around. > Even if what I'd said weren't an oversimplification, it wouldn't work to use the MAC address as the IAID, because it's unnecessarily big. I expect it to be rare that a single DHCP request will require 2^48 IAs. Yes, from a implementation standpoint, there is obviously no need for the whole MAC address to uniquely identify the request. My point was simply that since the IAID, at least in some cases (the oversimplified one), may actually map to an interface, then it would be more useful to know which interface it maps to. With that said, I have some questions regarding the proposed draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01. RFC 3315 mentions this: When a client sends a DHCP message to the All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message through the interface for which configuration information is being requested. However, the client MAY send the message through another interface attached to the same link So, would the hardware-addr-option (or link-layer option) identify the MAC of the interface on which the request was sent, or the MAC of the interface "for which configuration information is being requested"? Also, I recall a thread on the mailing list that discussed CPE routers which may request an address for the WAN-side interface via an IA_NA option along with an IA_PD request for the LAN-side interface. I believe the discussion was focused on the renew behavior. However, IIRC, some implementations may send the IA_NA and IA_PD in the same or separate requests. Regardless of one or two requests, the packets would (presumably) be sent over the WAN-side interface. In the situation where the client sends the IA_NA and IA_PD in the same request packet, the proposed link-layer address option would be the MAC of which interface - WAN or LAN? In the case of separate requests, would you then expect two different MACs? I think were I'm heading with this is that perhaps the link-layer option needs to be "inside" the IA option, not at the outermost message level of the packet. Greg On Thu, Mar 29, 2012 at 10:41 AM, Ted Lemon wrote: > > Ted (don't mean to call you out here, but it is prevalent to my > question) wrote this on the ISC DHCP list: > >>DUID+IAID uniquely identifies the interface; DUID uniquely identifies > the host. > > My question is can this be guaranteed? > > No, I was oversimplifying. The intent was that there might well be more > than one IAID per interface. In practice, I would expect an IA_NA and an > IA_TA to use different IAIDs, for instance. Similarly for IA_PD. It was > also intended that the client could ask for more than one set of IA_NA > addresses per interface if it wanted to present more than one identity to > the network. > > Even if what I'd said weren't an oversimplification, it wouldn't work to > use the MAC address as the IAID, because it's unnecessarily big. I expect > it to be rare that a single DHCP request will require 2^48 IAs. > --0015175d07bc1f7b9f04bc64bea2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Ted.

>=A0The intent was that there might well be mor= e than one IAID per interface. =A0=A0
> In practice, I would e= xpect an IA_NA and an IA_TA to use different IAIDs, for instance. =A0 Simil= arly for IA_PD.=A0

RFC 3315 states this:
   The IAID number space for the IA_TA op=
tion IAID number space is
   separate from the IA_NA option IAID number space.
Based on that statement, I was thinking that a typical implementation= might use the index of an interface as the IAID. =A0For example, eth0=3DIA= ID1. =A0Then, if an IA_NA, IA_TA, or IA_PD sent on eth0, would all use IAID= =3D1, and are distinguished by IA_TYPE as described in the text above. =A0H= owever, that obviously would not work if there are more than one IA of the = same type on that interface, as you described:

> It was also intended that the client could ask for= more than one set of IA_NA addresses per interface if it wanted to present= more than one identity to the network.

Yes, and I believe this is further clarified in R= FC 3315 with this text:
   A client must associate at least one distinct IA with ea=
ch of its
   network interfaces for which it is to request the assignment of IPv6
   addresses from a DHCP server.  The client uses the IAs assigned to an
   interface to obtain configuration information from a server for that
   interface.  Each IA must be associated with exactly one interface.

So, each IA is associated with exactly one interface, = but not necessarily the other way around.

> Eve= n if what I'd said weren't an oversimplification, it wouldn't w= ork to use the MAC address as the IAID, because it's unnecessarily big.= =A0 I expect it to be rare that a single DHCP request will require 2^48 IA= s.=A0

Yes, from a implementation standpoint, there is obvious= ly no need for the whole MAC address to uniquely identify the request. =A0M= y point was simply that since the IAID, at least in some cases (the oversim= plified one), may actually map to an interface, then it would be more usefu= l to know which interface it maps to.

With that said, I have some questions regarding the pro= posed=A0draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.

RFC 3315 mentions this:
   When a client sends a DHCP message to the
   All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
   through the interface for which configuration information is being
   requested.  However, the client MAY send the message through another
   interface attached to the same link
So, would the hardwa= re-addr-option (or link-layer option) identify the MAC of the interface on = which the request was sent, or the MAC of the interface "for which con= figuration information is being requested"?

Also, I recall a thread on the mailing list that discus= sed CPE routers which may request an address for the WAN-side interface via= an IA_NA option along with an IA_PD request for the LAN-side interface. = =A0I believe the discussion was focused on the renew behavior. =A0However, = IIRC, some implementations may send the IA_NA and IA_PD in the same or sepa= rate requests. =A0Regardless of one or two requests, the packets would (pre= sumably) be sent over the WAN-side interface. =A0In the situation where the= client sends the IA_NA and IA_PD in the same request packet, the proposed = link-layer address option would be the MAC of which interface - WAN or LAN?= =A0In the case of separate requests, would you then expect two different M= ACs? =A0I think were I'm heading with this is that perhaps the link-lay= er option needs to be "inside" the IA option, not at the outermos= t message level of the packet.

Greg

On Thu, Mar 29, 2012 at 10:41 AM, Ted L= emon <Ted.Lemon@nominum.com> wrote:
> Ted (don't mean to call you out here, but it is prevalent to = my question) wrote this on the ISC DHCP list:
>>DUID+IAID uniquely identifies the interface; DUID uniquely identifi= es the host.
> My question is can this be guaranteed?

No, I was oversimplifying. =A0 The intent was that there might well b= e more than one IAID per interface. =A0 In practice, I would expect an IA_N= A and an IA_TA to use different IAIDs, for instance. =A0 Similarly for IA_P= D. =A0 It was also intended that the client could ask for more than one set= of IA_NA addresses per interface if it wanted to present more than one ide= ntity to the network.

Even if what I'd said weren't an oversimplification, it wouldn'= t work to use the MAC address as the IAID, because it's unnecessarily b= ig. =A0 I expect it to be rare that a single DHCP request will require 2^48= IAs.

--0015175d07bc1f7b9f04bc64bea2-- From jiangsheng@huawei.com Thu Mar 29 10:20:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0551B21E8053 for ; Thu, 29 Mar 2012 10:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APxBadnzPjMy for ; Thu, 29 Mar 2012 10:20:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 111B321E801B for ; Thu, 29 Mar 2012 10:20:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU45602; Thu, 29 Mar 2012 13:20:05 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:17:51 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:17:57 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Fri, 30 Mar 2012 01:17:51 +0800 From: Sheng Jiang To: Ted Lemon , Alexandru Petrescu , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Review request for draft-ietf-dhc-host-gen-id Thread-Index: AQHNDYTEvKYY7dEar06J4LJG6pajkJaAxEiAgAABGgCAALb0XA== Date: Thu, 29 Mar 2012 17:17:49 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E47CD24@SZXEML506-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B921E47C59E@SZXEML506-MBS.china.huawei.com>, <4F746855.8050006@gmail.com>, <8D23D4052ABE7A4490E77B1A012B6307472D43BA@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D43BA@mbx-01.win.nominum.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Review request for draft-ietf-dhc-host-gen-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:20:07 -0000 Ted, The prefix is NOT always 64. In principle, it can be 0 to 128, even the one= assign to host. You can see this in ND prefix option as well: section 4.6.= 2 of RFC 2461. I am afraid this have to be bitfields. Actually, RFC3633 has already done b= itfields in DHCPv6, hasn't it? Alex, I don't see a reason why cannot it to be greater than 64. Looking at SLAAC,= RFC2462, it only defined prefix length + interface id length should be equ= al to 128. The interface id is typically be 64-bit long, but it is NOT a MU= ST. In principle, it can be other length as well as far as I understand. Best regards, Sheng ________________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf of Ted Lemo= n [Ted.Lemon@nominum.com] Sent: 29 March 2012 21:53 To: Alexandru Petrescu; dhcwg@ietf.org Subject: Re: [dhcwg] Review request for draft-ietf-dhc-host-gen-id > If not it should say so, and eventually encoding on 6bit instead of 8, > maybe. DHCP doesn't do bitfields. However, I think that the width of the prefix = is _always_ 64, so maybe we don't need to include a length at all? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg= From Ted.Lemon@nominum.com Thu Mar 29 14:45:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A446321E801F for ; Thu, 29 Mar 2012 14:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2xhTygVzIb0 for ; Thu, 29 Mar 2012 14:45:16 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id A45E421E8019 for ; Thu, 29 Mar 2012 14:45:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT3TX67cSL5PKIuHJB0V84TvfwwH6weOC@postini.com; Thu, 29 Mar 2012 14:45:15 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D45BF1B8217 for ; Thu, 29 Mar 2012 14:45:13 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CBD32190064; Thu, 29 Mar 2012 14:45:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 14:45:13 -0700 From: Ted Lemon To: Sheng Jiang , Alexandru Petrescu , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Review request for draft-ietf-dhc-host-gen-id Thread-Index: AQHNDYTEvKYY7dEar06J4LJG6pajkJaBv72A//+LmtiAAK6zgP//060q Date: Thu, 29 Mar 2012 21:45:13 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4619@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B921E47C59E@SZXEML506-MBS.china.huawei.com> <4F746855.8050006@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D43BA@mbx-01.win.nominum.com>, <5D36713D8A4E7348A7E10DF7437A4B921E47CD24@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E47CD24@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Review request for draft-ietf-dhc-host-gen-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:45:16 -0000 > The prefix is NOT always 64. In principle, it can be 0 to 128, even the > one assign to host. You can see this in ND prefix option as well: section > 4.6.2 of RFC 2461. I don't see a reason why cannot it to be greater than > 64. Looking at SLAAC, RFC2462, it only defined prefix length + interface > id length should be equal to 128. The interface id is typically be 64-bit > long, but it is NOT a MUST. In principle, it can be other length as well > as far as I understand. The text doesn't explicitly prevent it, but in practice there is no other w= idth that is allowed. The prefix can't really be wider than 64 bits, and = can't really be narrower. I'd be curious to hear if you know of some conc= rete example to the contrary, but it's my understanding that this is pretty= much written in stone. > I am afraid this have to be bitfields. Actually, RFC3633 has already done= bitfields in DHCPv6, hasn't it? No, prefix length is 8 bits in RFC3633. From Ted.Lemon@nominum.com Thu Mar 29 14:52:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CB821F8732 for ; Thu, 29 Mar 2012 14:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb+wQiPLGR90 for ; Thu, 29 Mar 2012 14:52:50 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4F721F850D for ; Thu, 29 Mar 2012 14:52:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKT3TZsaGLXMxmVY75BQPE3ElbJ46R5onK@postini.com; Thu, 29 Mar 2012 14:52:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 33C4C1B8131 for ; Thu, 29 Mar 2012 14:52:49 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2C334190061; Thu, 29 Mar 2012 14:52:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 14:52:49 -0700 From: Ted Lemon To: "A. Gregory Rabil" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] DUID+IAID Thread-Index: AQHNDbbP4FgtkXLiwESgwgUDJGkpD5aBV/GogACefoD//9jW1g== Date: Thu, 29 Mar 2012 21:52:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D462B@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:52:53 -0000 > So, would the hardware-addr-option (or link-layer option) identify the MA= C > of the interface on which the request was sent, or the MAC of the interfa= ce > "for which configuration information is being requested"? In practice there's no difference. But it doesn't identify the interface.= It provides additional information about the interface that can be used a= s a database key to associate devices to the DUID. A back-end database in= itialized by scanning the box a router came in might have four entries for = the four hardware addresses of that router. When a request comes in from = that router, the database entry for each hardware address could be updated = to refer to the same DUID. In this way we can tie an existing hardware ad= dress-based back-end database to DUID. That's the point of the exercise. > Also, I recall a thread on the mailing list that discussed CPE routers wh= ich may > request an address for the WAN-side interface via an IA_NA option along w= ith an > IA_PD request for the LAN-side interface. I believe the discussion was f= ocused on > the renew behavior. However, IIRC, some implementations may send the IA_= NA > and IA_PD in the same or separate requests. Regardless of one or two req= uests > the packets would (presumably) be sent over the WAN-side interface. In t= he > situation where the client sends the IA_NA and IA_PD in the same request = packet, > the proposed link-layer address option would be the MAC of which interfac= e - > WAN or LAN? In the case of separate requests, would you then expect two > different MACs? I think were I'm heading with this is that perhaps the l= ink-layer > option needs to be "inside" the IA option, not at the outermost message l= evel of the packet. The problem we are trying to solve is twofold. First, tying the mac addre= ss on a shipping box to a device making a query on the network using DUID. = Second, tying the chaddr field from a DHCPv4 message to the DUID of a DHC= Pv6 message. So consider the CPE router--it's sending its DHCPv4 packet o= n the upstream interface, and it's sending its DHCPv6 packet on the upstrea= m interface. In both cases, the hardware address we want to send is the h= ardware address of the upstream interface. It makes no sense to send the = hardware address of any of the downstream interfaces. From jiangsheng@huawei.com Thu Mar 29 16:02:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CB421F8525 for ; Thu, 29 Mar 2012 16:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqv3hWJWitOz for ; Thu, 29 Mar 2012 16:02:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C669121F852A for ; Thu, 29 Mar 2012 16:02:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU64855; Thu, 29 Mar 2012 19:02:14 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 16:00:48 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 16:00:54 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Fri, 30 Mar 2012 07:00:47 +0800 From: Sheng Jiang To: Ted Lemon , Alexandru Petrescu , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Review request for draft-ietf-dhc-host-gen-id Thread-Index: AQHNDYTEvKYY7dEar06J4LJG6pajkJaAxEiAgAABGgCAALb0XP//zPWAgACY9OQ= Date: Thu, 29 Mar 2012 23:00:46 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E47CE71@SZXEML506-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B921E47C59E@SZXEML506-MBS.china.huawei.com> <4F746855.8050006@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D43BA@mbx-01.win.nominum.com>, <5D36713D8A4E7348A7E10DF7437A4B921E47CD24@SZXEML506-MBS.china.huawei.com>, <8D23D4052ABE7A4490E77B1A012B6307472D4619@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4619@mbx-01.win.nominum.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Review request for draft-ietf-dhc-host-gen-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 23:02:15 -0000 > The prefix is NOT always 64. In principle, it can be 0 to 128, even the > one assign to host. You can see this in ND prefix option as well: section > 4.6.2 of RFC 2461. I don't see a reason why cannot it to be greater than > 64. Looking at SLAAC, RFC2462, it only defined prefix length + interface > id length should be equal to 128. The interface id is typically be 64-bit > long, but it is NOT a MUST. In principle, it can be other length as well > as far as I understand. The text doesn't explicitly prevent it, but in practice there is no other w= idth that is allowed. The prefix can't really be wider than 64 bits, and = can't really be narrower. I'd be curious to hear if you know of some conc= rete example to the contrary, but it's my understanding that this is pretty= much written in stone. The only current instance is the IPv4-embedded IPv6, which is no in= use anymore by my understanding. But it is safer to keep prefix length. I = heard some story that in other protocol using prefix, they get rid of prefi= x length, but run into trouble during IESG review. The format of prefix len= gth plus 128-bit prefix field is almost standard. I see no harm to keep it = this way. > I am afraid this have to be bitfields. Actually, RFC3633 has already done= bitfields in DHCPv6, hasn't it? No, prefix length is 8 bits in RFC3633. I misunderstanding the meaning of bitfields. Yes, DHCP options much= be times of 8 bits. So, if we are going to keep prefix length. It has to b= e 8 bits, as it is now. Sheng= From greg.rabil@jagornet.com Thu Mar 29 18:17:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9BA21E8043 for ; Thu, 29 Mar 2012 18:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1mVONsrr2cw for ; Thu, 29 Mar 2012 18:17:07 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F18C021E8020 for ; Thu, 29 Mar 2012 18:17:06 -0700 (PDT) Received: by bkuw5 with SMTP id w5so90200bku.31 for ; Thu, 29 Mar 2012 18:17:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-gm-message-state:content-type; bh=7ri7MHUWq0ncWC/KAVNIePSQrAMFvjqcXmCAuanrW6Y=; b=iXuwpqkzcnG2Se7YMhE++qOpCrt6yHZrkuc7/iTm2n9WwPUUZ2HLy/AXs3V+tHmQI+ YALo5/BzIoU3262OhknJ0Hq7NjqA4S1LPUnF1T3d16+letW7JjwDMgGAKrHV/p3cYrN7 G0DKv3OiVj3peg1VKN01bjxbXmWEI6BmflvyAlWLvC1SP+hh02/KROVsZOtkexKXe3py FZ2NuLPDJsY+SaROoAWxRNzR0kKJO5ri/Q1dg/2rQ+PxI7hbirx/1prXtD4O2IR29+G4 U7PO8DyXCh+WsgPuD9qBaG0w4z97Vr9HoodYoZo0KXdYstStMVheidU7nY25lKqMrMWs 1yEg== MIME-Version: 1.0 Received: by 10.204.154.202 with SMTP id p10mr101056bkw.79.1333070225888; Thu, 29 Mar 2012 18:17:05 -0700 (PDT) Received: by 10.204.98.198 with HTTP; Thu, 29 Mar 2012 18:17:05 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D462B@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D462B@mbx-01.win.nominum.com> Date: Thu, 29 Mar 2012 21:17:05 -0400 Message-ID: From: "A. Gregory Rabil" To: "dhcwg@ietf.org" X-Gm-Message-State: ALoCoQl0Z33umKOEi+JbM9k1lFeiZHwqtwTQcPEO2VSLe+/njIr0qWhe1EUQ7sRLcs+B+LbtxJoQ Content-Type: multipart/alternative; boundary=0015175d07bc46565304bc6b9900 Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 01:17:08 -0000 --0015175d07bc46565304bc6b9900 Content-Type: text/plain; charset=ISO-8859-1 > In practice there's no difference. But it doesn't identify the interface. > It provides additional information about the interface that can be used as a database key to associate devices to the DUID. I am not sure I understand that. Why would the proposed hardware-addr-option not identify the interface? In DHCPv4, we only know the interface identifier (chaddr), we can't really identify the device itself. That is, we can't correlate multiple interfaces to the same device without resorting to something less than ideal, such as the hostname. In DHCPv6 (as it stands now), we can identify the device (DUID), but not the interface. My understanding of the proposal is that the MAC address is *added* to the request as an option, so we would have both the DUID and the MAC, thus allowing us to identify both the device and the interface, which is good IMO. >The problem we are trying to solve is twofold. First, tying the mac address on a shipping box to a device making a query on the network using >DUID. Second, tying the chaddr field from a DHCPv4 message to the DUID of a DHCPv6 message. So consider the CPE router--it's sending >its DHCPv4 packet on the upstream interface, and it's sending its DHCPv6 packet on the upstream interface. In both cases, the hardware >address we want to send is the hardware address of the upstream interface. It makes no sense to send the hardware address of any of the >downstream interfaces. Yes, I believe I understand this use case, and I agree that my example with the downstream interface may not have been a good choice. However, consider a more complicated example where a device has multiple upstream interfaces. As I read that snippet from RFC 3315, such a device may send multiple IAs in one request where, for example, one IA_NA is for upstream interface A, and a second IA_NA is for upstream interface B. If this is possible, then I was simply suggesting that the proposed hardware-addr-option be an IA-level option rather than a message-level option, so as to identify each interface. Greg --0015175d07bc46565304bc6b9900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > In practice there's no difference. =A0 But it doesn't identify= the interface. =A0
> It provides additional information about the i= nterface that can be used as a database key to associate devices to the DUI= D.

I am not sure I understand that. =A0Why would the proposed hardware-add= r-option not identify the interface?

In DHCPv4, we only know = the interface identifier (chaddr), we can't really identify the device = itself. =A0That is, we can't correlate multiple interfaces to the same = device without resorting to something less than ideal, such as the hostname= . =A0In DHCPv6 (as it stands now), we can identify the device (DUID), but n= ot the interface. =A0My understanding of the proposal is that the MAC addre= ss is *added* to the request as an option, so we would have both the DUID a= nd the MAC, thus allowing us to identify both the device and the interface,= which is good IMO.

>The problem we are trying to solve is twofold. =A0 = First, tying the mac address on a shipping box to a device making a query o= n the network using >DUID. =A0 Second, tying the chaddr field from a DHC= Pv4 message to the DUID of a DHCPv6 message. =A0 So consider the CPE router= --it's sending >its DHCPv4 packet on the upstream interface, and it&= #39;s sending its DHCPv6 packet on the upstream interface. =A0 In both case= s, the hardware >address we want to send is the hardware address of the = upstream interface. =A0 It makes no sense to send the hardware address of a= ny of the >downstream interfaces.

Yes, I believe I understand this use case, and I agree = that my example with the downstream interface may not have been a good choi= ce. =A0However, consider a more complicated example where a device=A0has mu= ltiple upstream interfaces. =A0As I read that snippet from RFC 3315, such a= device may send multiple IAs in one request where, for example, one IA_NA = is for upstream interface A, and a second IA_NA is for upstream interface B= . =A0If this is possible, then I was simply suggesting that the proposed ha= rdware-addr-option be an IA-level option rather than a message-level option= , so as to identify each interface.

Greg
--0015175d07bc46565304bc6b9900-- From Ted.Lemon@nominum.com Thu Mar 29 23:23:04 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445E121E802B for ; Thu, 29 Mar 2012 23:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.192 X-Spam-Level: X-Spam-Status: No, score=-106.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gppFbRbBaqDS for ; Thu, 29 Mar 2012 23:23:03 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 32F9421E8095 for ; Thu, 29 Mar 2012 23:23:03 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT3VRRhSaj73ry6V6IVmAX1ygHuDdLsNt@postini.com; Thu, 29 Mar 2012 23:23:03 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 49BBF1B8225 for ; Thu, 29 Mar 2012 23:23:02 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3DEF7190064; Thu, 29 Mar 2012 23:23:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 23:22:56 -0700 From: Ted Lemon To: "A. Gregory Rabil" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] DUID+IAID Thread-Index: AQHNDbbP4FgtkXLiwESgwgUDJGkpD5aBV/GogACefoD//9jW1oAAsEmA///d68w= Date: Fri, 30 Mar 2012 06:22:55 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D46D5@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D462B@mbx-01.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 06:23:04 -0000 > I am not sure I understand that. Why would the proposed hardware-addr-op= tion > not identify the interface? Because it is not an identifier. It is a hint. If you call it an identi= fier, someone will start using it as one. > My understanding of the proposal is that the MAC address is *added* to th= e request > as an option, so we would have both the DUID and the MAC, thus allowing u= s to > identify both the device and the interface, which is good IMO. In principle there's nothing incorrect about this statement, but in practic= e there is no protocol need to identify the interface. So if you call it = an identifier, people are going to confuse it with the DHCPv4 way of identi= fying *clients*, and not understand that you mean it to be identifying *int= erfaces*. So it's better to not put it that way. > As I read that snippet from RFC 3315, such a device may send multiple > IAs in one request where, for example, one IA_NA is for upstream interfac= e > A, and a second IA_NA is for upstream interface B. If this is possible, = then > I was simply suggesting that the proposed hardware-addr-option be an > IA-level option rather than a message-level option, so as to identify eac= h interface. This is a use case that was advocated at the time RFC3315 was written, but = I didn't understand at the time under what circumstances this would happen,= and as the protocol has evolved, I think it's pretty clear that it isn't a= plausible use case. If you want to configure an interface, you send a DH= CP packet on that interface, not on some other interface. It's possible that you might want to use DHCP to allocate an address for a = tunnel endpoint, but in that case there is no physical interface, and the M= AC address that the relay agent will add to the packet will be the address = of the physical interface, not the tunnel, which has no MAC address. So t= his is another reason not to call this an "interface identifier." It's th= e MAC address of the interface out which the DHCP packet was sent. From Ted.Lemon@nominum.com Thu Mar 29 23:40:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCA421F8582 for ; Thu, 29 Mar 2012 23:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gNCEFZBgJFb for ; Thu, 29 Mar 2012 23:40:29 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0289921E8025 for ; Thu, 29 Mar 2012 23:40:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT3VVWnH0iiPT9wOJ6m4X9cCNqYauR5/x@postini.com; Thu, 29 Mar 2012 23:40:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 90E7F1B8237 for ; Thu, 29 Mar 2012 23:40:25 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 88959190064; Thu, 29 Mar 2012 23:40:25 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 23:40:25 -0700 From: Ted Lemon To: Sheng Jiang , Alexandru Petrescu , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Review request for draft-ietf-dhc-host-gen-id Thread-Index: AQHNDYTEvKYY7dEar06J4LJG6pajkJaBv72A//+LmtiAAK6zgP//060qgACMJQCAAAqm0A== Date: Fri, 30 Mar 2012 06:40:25 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D46F8@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B921E47C59E@SZXEML506-MBS.china.huawei.com> <4F746855.8050006@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D43BA@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B921E47CD24@SZXEML506-MBS.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307472D4619@mbx-01.win.nominum.com>, <5D36713D8A4E7348A7E10DF7437A4B921E47CE71@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E47CE71@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Review request for draft-ietf-dhc-host-gen-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 06:40:30 -0000 >The only current instance is the IPv4-embedded IPv6, which is no in > use anymore by my understanding. But it is safer to keep prefix length. Mainly it's not something you'd use in DHCP. IPv4-embedded is not used as= it was originally intended, but there are uses for it. > I heard some story that in other protocol using prefix, they get rid of > prefix length, but run into trouble during IESG review. The format of > prefix length plus 128-bit prefix field is almost standard. I see no harm > to keep it this way. This is a fair point. From tomasz.mrugalski@gmail.com Fri Mar 30 01:01:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F67A21F8802 for ; Fri, 30 Mar 2012 01:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9IIoJAjWHev for ; Fri, 30 Mar 2012 01:01:49 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3119021F875B for ; Fri, 30 Mar 2012 01:01:49 -0700 (PDT) Received: by bkuw5 with SMTP id w5so272477bku.31 for ; Fri, 30 Mar 2012 01:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=AfJdBsWs0d+AOzlQTyQvDdl8le/8mnlJOc+/qNyj2Y8=; b=CU23N01//WrujA4BHGR/whZYf7Dggw3t8SAuGZYglHNdTfBnt8bSN83dwVGEKS63bf y4P5djmJpJGw4A+OPdarDUMqQxMOQt2jF2xD0myTwfiD4I5BLuwuYg9I+CvU5lPCFIIX l6RtTQ/bed19oJqVtSb7cG/5NEYotabNRM5zcClW/4R5nCl/h87amk8Noz5XcJrddJgb TgSXIpBAbuiyOMu5vjXQl8+U2FZ82bkZcQUsayaMUV4DJ4pmVKKhuk2xkWb0+N0uNqwo KQ8FcPvMhHIOlCVR/f/OMuTCXKxfU6E00mFp1VshdiwVom8RrN0cXUZ878LfqE5t6bHZ WB4Q== Received: by 10.204.143.151 with SMTP id v23mr530789bku.63.1333094508203; Fri, 30 Mar 2012 01:01:48 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id b3sm9853946bki.16.2012.03.30.01.01.46 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 01:01:47 -0700 (PDT) Message-ID: <4F756869.7010404@gmail.com> Date: Fri, 30 Mar 2012 10:01:45 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:01:50 -0000 On 12-03-29 16:41, Ted Lemon wrote: >> Ted (don't mean to call you out here, but it is prevalent to my >> question) wrote this on the ISC DHCP list: >>> DUID+IAID uniquely identifies the interface; DUID uniquely >>> identifies the host. >> My question is can this be guaranteed? > > No, I was oversimplifying. The intent was that there might well be > more than one IAID per interface. In practice, I would expect an > IA_NA and an IA_TA to use different IAIDs, for instance. Similarly > for IA_PD. It was also intended that the client could ask for more That is not guaranteed. I just checked RFC3315 and it is somewhat contradictory. Is sending IA_NA and IA_PD legal? Page 11 says that "Each IA has an IAID, which is chosen to be unique among all IAIDs for IAs belonging to that client.". This suggest that the same iaid for IA_NA and IA_PD is not valid. On the other hand, in section 4.2 there following text "A binding containing information about an IA is indexed by the tuple .". It suggests that IAID number spaces for different IA types are orthogonal. Oh well, yet another thing to clarify in 3315bis. > than one set of IA_NA addresses per interface if it wanted to present > more than one identity to the network. Agree. There may be many IA_NA instances (or IA_PD or other IA types) in a single message. > Even if what I'd said weren't an oversimplification, it wouldn't work > to use the MAC address as the IAID, because it's unnecessarily big. Some implementations use part of MAC. I'm not sure what were the original reasons for this, but that is mostly valid approach. > I expect it to be rare that a single DHCP request will require 2^48 > IAs. I expect it as well. Let's keep iaid as it is now - 32 bit is enough. And if some brave soul insists on sending 2^48 IAs, he would have to make sure that his DHCPv6 packets are fragmented properly. Which brings us to yet another possible 3315bit thing. While I haven't seen any DHCPv6 messages that are even close to 1280 bytes, it is something that could possibly be clarified. Tomek From Francis.Dupont@fdupont.fr Fri Mar 30 01:27:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD3021F8867 for ; Fri, 30 Mar 2012 01:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdMiMpmlza+X for ; Fri, 30 Mar 2012 01:27:00 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E2C0021F8865 for ; Fri, 30 Mar 2012 01:26:59 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2U8Qx51078004; Fri, 30 Mar 2012 10:26:59 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203300826.q2U8Qx51078004@givry.fdupont.fr> From: Francis Dupont To: "A. Gregory Rabil" In-reply-to: Your message of Thu, 29 Mar 2012 21:17:05 EDT. Date: Fri, 30 Mar 2012 10:26:59 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:27:00 -0000 In your previous mail you wrote: > I am not sure I understand that. Why would the proposed > hardware-addr-option not identify the interface? => I raise here a silly but real concern: the common assumption a MAC address is unique to a physical interface is *false*: the IEEE spec is loose and uses the term device, it is commonly but *not universally* interpreted as NIC, i.e., there is at least one important vendor which assigns a MAC address to the whole box. Regards Francis.Dupont@fdupont.fr From Ted.Lemon@nominum.com Fri Mar 30 02:27:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118F521F8600 for ; Fri, 30 Mar 2012 02:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.191 X-Spam-Level: X-Spam-Status: No, score=-106.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs2W5Flg2rC4 for ; Fri, 30 Mar 2012 02:27:32 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id D6E3221F87B9 for ; Fri, 30 Mar 2012 02:27:30 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT3V8gnSqIlvtxC+T/lOI9ucgyTS5aytI@postini.com; Fri, 30 Mar 2012 02:27:30 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C48D21B8237 for ; Fri, 30 Mar 2012 02:27:29 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B9986190064; Fri, 30 Mar 2012 02:27:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 02:27:29 -0700 From: Ted Lemon To: Francis Dupont , "A. Gregory Rabil" Thread-Topic: [dhcwg] DUID+IAID Thread-Index: AQHNDk7f4FgtkXLiwESgwgUDJGkpD5aCkfCb Date: Fri, 30 Mar 2012 09:27:29 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> References: Your message of Thu, 29 Mar 2012 21:17:05 EDT. ,<201203300826.q2U8Qx51078004@givry.fdupont.fr> In-Reply-To: <201203300826.q2U8Qx51078004@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:27:33 -0000 > I raise here a silly but real concern: the common assumption > a MAC address is unique to a physical interface is *false*: Right, that's why we don't want to use it as an identifier. From greg.rabil@jagornet.com Fri Mar 30 07:04:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04121F8678 for ; Fri, 30 Mar 2012 07:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUO2LTtpU0B7 for ; Fri, 30 Mar 2012 07:04:42 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE4D621F85D8 for ; Fri, 30 Mar 2012 07:04:41 -0700 (PDT) Received: by bkuw5 with SMTP id w5so620687bku.31 for ; Fri, 30 Mar 2012 07:04:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=kAwQKXJ1UM3+HYBcoVwJQrkMVv9POtSwPqCaLfX4aGs=; b=Y3s/uJ4oXhVFz+t8ngKu9VktKpFF45Ritn7fCAb0OycWSqfpoW3I5ErRuw9jvatcDy 9otjCHP8JRewEUDBQdIpggnU7qkz4YQWKWt7Ff6bqkvBQBHv9XqcQUXXTCe8dRS3yHsf B5nw8MPTWAE1is/oMImJLrSKG3udCvtCbuflrtotqjmh27jrWP6ctICGSx0S9GNilaCW SjA8/Pbm5+XhkFfIAvTwt9RNanS3P/V6yCCMwbkP2ergk6y9F40TMJBReMEt+j3AJ7ep iQiH5/0W8T7LZKzxRQB7q9YASDvC94jaYafGuDWoVVUcDoYeUPCN71qrTwXZWpeYsr2i Xa1A== MIME-Version: 1.0 Received: by 10.204.128.152 with SMTP id k24mr960542bks.127.1333116280791; Fri, 30 Mar 2012 07:04:40 -0700 (PDT) Received: by 10.204.22.4 with HTTP; Fri, 30 Mar 2012 07:04:40 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> Date: Fri, 30 Mar 2012 10:04:40 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon X-Gm-Message-State: ALoCoQmcoRC4NswmRmCr6fSTVMIMT0H51Z9nLMw0ScEZWMDUv2cD/LLkOnwUAmJRUCsOW+VZ9T4J Content-Type: multipart/alternative; boundary=0015174c3c205c60dc04bc765299 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:04:42 -0000 --0015174c3c205c60dc04bc765299 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 30, 2012 at 5:27 AM, Ted Lemon wrote: > > I raise here a silly but real concern: the common assumption > > a MAC address is unique to a physical interface is *false*: > > Right, that's why we don't want to use it as an identifier. > Okay, so given that the MAC address is not unique, then in order to "provision" devices (aka static binding, reservation, or manual dhcp), the administrator must know both the DUID and the MAC of the device to be provisioned, correct? Greg --0015174c3c205c60dc04bc765299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 30, 2012 at 5:27 AM, Te= d Lemon=A0<Te= d.Lemon@nominum.com>=A0wrote:
> I raise here a silly but real concern: the common as= sumption
> a MAC address is unique to a physical interface is *false*= :

Right, that's why we don't want to use it as an iden= tifier.

Okay, so given that th= e MAC address is not unique, then in order to "provision" devices= (aka static binding, reservation, or manual dhcp), the administrator must = know both the DUID and the MAC of the device to be provisioned, correct?
Greg

--0015174c3c205c60dc04bc765299-- From Ted.Lemon@nominum.com Fri Mar 30 07:07:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0B321F8593 for ; Fri, 30 Mar 2012 07:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.193 X-Spam-Level: X-Spam-Status: No, score=-106.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSGZwv6m7vfr for ; Fri, 30 Mar 2012 07:07:29 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 72B3C21F84EF for ; Fri, 30 Mar 2012 07:07:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT3W+H+NKPWxP9wor52XEk9ZnFAzdGxq0@postini.com; Fri, 30 Mar 2012 07:07:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6E5851B80AD for ; Fri, 30 Mar 2012 07:07:27 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 60A99190061; Fri, 30 Mar 2012 07:07:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 07:07:27 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] DUID+IAID Thread-Index: AQHNDk7f4FgtkXLiwESgwgUDJGkpD5aCkfCbgADC4wD//4tAkg== Date: Fri, 30 Mar 2012 14:07:27 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com> References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:07:31 -0000 > Okay, so given that the MAC address is not unique, then in order to "prov= ision" > devices (aka static binding, reservation, or manual dhcp), the administra= tor must > know both the DUID and the MAC of the device to be provisioned, correct? If you "provision" you mean "connect to a back-office database that only ha= s the MAC as a key" then yes. Otherwise no. From greg.rabil@jagornet.com Fri Mar 30 07:19:04 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDC921F86D1 for ; Fri, 30 Mar 2012 07:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjTVJIQvhdHm for ; Fri, 30 Mar 2012 07:19:03 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2B21F86C6 for ; Fri, 30 Mar 2012 07:19:03 -0700 (PDT) Received: by bkuw5 with SMTP id w5so636598bku.31 for ; Fri, 30 Mar 2012 07:19:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=y8gyJiNLbc3oCpmI3hlO2hOoNhtYOQ2L4LDfn1NkxHw=; b=Oi/C9oa96MJOpHvlmTu4THcVoIiW23URTiQJfPqi/RHcK9YugEU51vP1ZvuS+eqj9d 4oOTwGgkasZah/2x3cHkZ3NE5RCvOVf7xierJFc5zfScviG3bGIhEs6Zf/y2gL9GUUMH vQTQJqnUh4R3051aDxDDqWtb41unvsCm2Jm/NFa0nqNBkqgD/Q8S3pguXKK4YJe3H13Q ppUhzTWCdVu9GUeyIlKXXV36YEqpRpIHQHB5xSdJoJENMr7pK3vTFx8KYfwG6PlrfNrt UTMXs6Q/UKhm256Lc2RMhgALE2oSMufHXeSmxPRbU0rwg4MbxFF7MCgI8GTIunVqcbb2 HyRw== MIME-Version: 1.0 Received: by 10.204.150.78 with SMTP id x14mr1024470bkv.114.1333117142570; Fri, 30 Mar 2012 07:19:02 -0700 (PDT) Received: by 10.204.22.4 with HTTP; Fri, 30 Mar 2012 07:19:02 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com> References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com> Date: Fri, 30 Mar 2012 10:19:02 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon X-Gm-Message-State: ALoCoQn74qpuXxPxoh/sf2yHKHUhEMkHgx3GGrNxGfOH1BFEHMSnMENpxPjr0dCYoQcbE+k7u8ej Content-Type: multipart/alternative; boundary=0015175df040ba16e404bc7685fd Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:19:04 -0000 --0015175df040ba16e404bc7685fd Content-Type: text/plain; charset=ISO-8859-1 In the case where a device only has one interface, then clearly only the DUID is needed to provision it, or assign a specific address to it in the case of a static-binding/reservation. If devices have multiple interfaces, then the DUID is not enough to uniquely reserve an address for each interface (wired and wireless, for example). In that case, you need the DUID+MAC. Greg On Fri, Mar 30, 2012 at 10:07 AM, Ted Lemon wrote: > > Okay, so given that the MAC address is not unique, then in order to > "provision" > > devices (aka static binding, reservation, or manual dhcp), the > administrator must > > know both the DUID and the MAC of the device to be provisioned, correct? > > If you "provision" you mean "connect to a back-office database that only > has the MAC as a key" then yes. Otherwise no. > --0015175df040ba16e404bc7685fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the case where a device only has one interface, then clearly only the DU= ID is needed to provision it, or assign a specific address to it in the cas= e of a static-binding/reservation. =A0If devices have multiple interfaces, = then the DUID is not enough to uniquely reserve an address for each interfa= ce (wired and wireless, for example). =A0In that case, you need the DUID+MA= C.

Greg

On Fri, Mar 30, 2012 at 10:07 AM, Ted Lemon= <Ted.Lemon@n= ominum.com> wrote:
> Okay, so given that the MAC address is not unique, t= hen in order to "provision"
> devices (aka static binding, reservation, or manual dhcp), the adminis= trator must
> know both the DUID and the MAC of the device to be provisioned, correc= t?

If you "provision" you mean "connect to a back-office = database that only has the MAC as a key" then yes. =A0 Otherwise no.

--0015175df040ba16e404bc7685fd-- From Ted.Lemon@nominum.com Fri Mar 30 07:58:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ED321F85CC for ; Fri, 30 Mar 2012 07:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.891 X-Spam-Level: X-Spam-Status: No, score=-105.891 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeX-9XwS819c for ; Fri, 30 Mar 2012 07:58:38 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0603B21F85C6 for ; Fri, 30 Mar 2012 07:58:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT3XKHXGC3GpDQePCjXdeg20tLJPY0xhC@postini.com; Fri, 30 Mar 2012 07:58:38 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C67581B824D for ; Fri, 30 Mar 2012 07:58:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A7476190064; Fri, 30 Mar 2012 07:58:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 07:58:36 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] DUID+IAID Thread-Index: AQHNDk7f4FgtkXLiwESgwgUDJGkpD5aCkfCbgADC4wD//4tAkoAAeMQA//+VNoI= Date: Fri, 30 Mar 2012 14:58:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4986@mbx-01.win.nominum.com> References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:58:38 -0000 > In the case where a device only has one interface, then clearly only the = DUID > is needed to provision it, or assign a specific address to it in the case= of a > static-binding/reservation. If devices have multiple interfaces, then th= e DUID > is not enough to uniquely reserve an address for each interface (wired an= d > wireless, for example). In that case, you need the DUID+MAC. No, that's what IAID is for. DUID+IAID provides a unique identifier that = allows a client to configure multiple interfaces, or multiple network ident= ities, using a consistent DUID. MAC address is _not_ related to this. A= t all. From sthaug@nethelp.no Fri Mar 30 08:02:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514D721F85D8 for ; Fri, 30 Mar 2012 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DpbD-+ClR8L for ; Fri, 30 Mar 2012 08:02:52 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 4206821F85D1 for ; Fri, 30 Mar 2012 08:02:52 -0700 (PDT) Received: (qmail 76579 invoked from network); 30 Mar 2012 15:02:50 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 30 Mar 2012 15:02:50 -0000 Date: Fri, 30 Mar 2012 17:02:50 +0200 (CEST) Message-Id: <20120330.170250.74676247.sthaug@nethelp.no> To: greg.rabil@jagornet.com From: sthaug@nethelp.no In-Reply-To: References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Francis.Dupont@fdupont.fr, Ted.Lemon@nominum.com Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:02:53 -0000 > > > I raise here a silly but real concern: the common assumption > > > a MAC address is unique to a physical interface is *false*: > > > > Right, that's why we don't want to use it as an identifier. > > Okay, so given that the MAC address is not unique, then in order to > "provision" devices (aka static binding, reservation, or manual dhcp), the > administrator must know both the DUID and the MAC of the device to be > provisioned, correct? The assumption that the MAC address is unique is indeed false. In addition to the one-MAC-per-box model (Sun at least *used to* have this), you also have customers cloning a MAC address they have found on a web page, and similar fun stuff. Providers with a large pool of DHCP customers are almost guaranteed to have several duplicates. However, in practice the MAC address is for the most part good enough, and I see no need for both DUID and MAC for static address assignment. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From greg.rabil@jagornet.com Fri Mar 30 08:03:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8390D21F869D for ; Fri, 30 Mar 2012 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 712Uu+SrQPow for ; Fri, 30 Mar 2012 08:03:12 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4D3A21F8663 for ; Fri, 30 Mar 2012 08:03:11 -0700 (PDT) Received: by bkuw5 with SMTP id w5so690594bku.31 for ; Fri, 30 Mar 2012 08:03:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=E9Cocr4KeUO8WeHo4ujSWE1FmI15z963HzIM/pMd+LI=; b=U4lpNTVahHjkXFdMxCCtrNzuuOa/N7nC7Dqz6j1UjKYnSjOKAAYAQxxk7EONIGc8LM p9GJmub+ME9x/bQfblHrSjBiMOb75ogdxKpyPoVWgojHNbEWN83vJR6dCrYXayK4eE8u uyONnfquHhrJL4nijRiKpBodNztf6O0+VGe2OJXH+9tRsFI04jrj3uiW0Hbktto4GsJj VK0idil4ciBjXpod1U+vX16YApwoF5rOMiz1VeIAzQHQQJCENQnAAEVBkQaVKrHqVF7E rs479g4a62e1dQ42PatWNCKL5rSk4buUJ/+OW4W9wzp/1V2xTkh57JIMmFEeJ/eZ90w6 7A8g== MIME-Version: 1.0 Received: by 10.205.137.15 with SMTP id im15mr1117060bkc.54.1333119790331; Fri, 30 Mar 2012 08:03:10 -0700 (PDT) Received: by 10.204.22.4 with HTTP; Fri, 30 Mar 2012 08:03:10 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4986@mbx-01.win.nominum.com> References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4986@mbx-01.win.nominum.com> Date: Fri, 30 Mar 2012 11:03:10 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon X-Gm-Message-State: ALoCoQmn+wr3lnSlOyJsDcFhHp+q4tXup5Dt+UR/Fmbl6DeyOIXV/sN4o7pFyEE/WyPPPuBtSkb3 Content-Type: multipart/alternative; boundary=000e0ce0f68e8bb72204bc772321 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:03:12 -0000 --000e0ce0f68e8bb72204bc772321 Content-Type: text/plain; charset=ISO-8859-1 If I want to assign a specific address to the wired interface and a separate, specific address to the wireless interface, how do I know what the IAID will be for each of them? On Fri, Mar 30, 2012 at 10:58 AM, Ted Lemon wrote: > > In the case where a device only has one interface, then clearly only the > DUID > > is needed to provision it, or assign a specific address to it in the > case of a > > static-binding/reservation. If devices have multiple interfaces, then > the DUID > > is not enough to uniquely reserve an address for each interface (wired > and > > wireless, for example). In that case, you need the DUID+MAC. > > No, that's what IAID is for. DUID+IAID provides a unique identifier that > allows a client to configure multiple interfaces, or multiple network > identities, using a consistent DUID. MAC address is _not_ related to > this. At all. > --000e0ce0f68e8bb72204bc772321 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If I want to assign a specific address to the wired interface and a separat= e, specific address to the wireless interface, how do I know what the IAID = will be for each of them?

On Fri, Mar 30,= 2012 at 10:58 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
> In the case where a d= evice only has one interface, then clearly only the DUID
> is needed to provision it, or assign a specific address to it in the c= ase of a
> static-binding/reservation. =A0If devices have multiple interfaces, th= en the DUID
> is not enough to uniquely reserve an address for each interface (wired= and
> wireless, for example). =A0In that case, you need the DUID+MAC.

No, that's what IAID is for. =A0 DUID+IAID provides a unique iden= tifier that allows a client to configure multiple interfaces, or multiple n= etwork identities, using a consistent DUID. =A0 MAC address is _not_ relate= d to this. =A0 At all.

--000e0ce0f68e8bb72204bc772321-- From Ted.Lemon@nominum.com Fri Mar 30 08:12:20 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970B621F84AA for ; Fri, 30 Mar 2012 08:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-wKaQrm2Uu2 for ; Fri, 30 Mar 2012 08:12:20 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id D56CE21F84A6 for ; Fri, 30 Mar 2012 08:12:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKT3XNU7pLY2DKxUAB2neXveDLkzjzo3az@postini.com; Fri, 30 Mar 2012 08:12:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1ACB51B8237 for ; Fri, 30 Mar 2012 08:12:19 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 116EF190064; Fri, 30 Mar 2012 08:12:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 08:12:19 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] DUID+IAID Thread-Index: AQHNDk7f4FgtkXLiwESgwgUDJGkpD5aCkfCbgADC4wD//4tAkoAAeMQA//+VNoKAAHcfAP//jNrq Date: Fri, 30 Mar 2012 15:12:19 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D49C0@mbx-01.win.nominum.com> References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4986@mbx-01.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:12:20 -0000 > If I want to assign a specific address to the wired interface and a separ= ate, specific address to the wireless interface, how do I know what the IAI= D will be for each of them? You find out when you get a DHCP packet from each interface, and each packe= t contains a DUID+IAID, and also contains the hardware address (assuming th= at you already know which hardware address corresponds to which interface). From jhutz@cmu.edu Fri Mar 30 09:39:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4721B21F864B for ; Fri, 30 Mar 2012 09:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHYBQB028QB4 for ; Fri, 30 Mar 2012 09:39:04 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id A853721F8645 for ; Fri, 30 Mar 2012 09:39:04 -0700 (PDT) Received: from [192.168.33.144] (c-67-165-85-247.hsd1.pa.comcast.net [67.165.85.247]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q2UGd10O018935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2012 12:39:02 -0400 (EDT) From: Jeffrey Hutzelman To: Ted Lemon In-Reply-To: <25900_1333088587_q2U6N6Ed025358_8D23D4052ABE7A4490E77B1A012B6307472D46D5@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D462B@mbx-01.win.nominum.com> , <25900_1333088587_q2U6N6Ed025358_8D23D4052ABE7A4490E77B1A012B6307472D46D5@mbx-01.win.nominum.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 30 Mar 2012 12:39:01 -0400 Message-ID: <1333125541.12176.49.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: "dhcwg@ietf.org" , jhutz@cmu.edu Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 16:39:05 -0000 On Fri, 2012-03-30 at 06:22 +0000, Ted Lemon wrote: > > I am not sure I understand that. Why would the proposed hardware-addr-option > > not identify the interface? > > Because it is not an identifier. It is a hint. If you call it an > identifier, someone will start using it as one. It is an identifier, or at least the IEEE tries fairly hard to make it one. It's just not an identifier that's guaranteed to be bound to anything useful to DHCP, and especially not to the client as a whole. Note that one reason you can't use a MAC address as an identifier _at the protocol layer_ is because some clients will end up using the same MAC address on multiple interfaces. For example, until only a few years ago, Sun boxes had a single MAC address for the entire machine, and used that address for every interface. > > My understanding of the proposal is that the MAC address is *added* to the request > > as an option, so we would have both the DUID and the MAC, thus allowing us to > > identify both the device and the interface, which is good IMO. > > In principle there's nothing incorrect about this statement, but in > practice there is no protocol need to identify the interface. True -- the _protocol_ has no such need. But that doesn't change whether the hardware address is in fact an identifier. More importantly, the question of whether this is an "identifier" or not is a pointless distraction from the original question, which was about _which interface's_ hardware address the option is expected to contain. > It's possible that you might want to use DHCP to allocate an address > for a tunnel endpoint, but in that case there is no physical > interface, and the MAC address that the relay agent will add to the > packet will be the address of the physical interface, not the tunnel, > which has no MAC address. So this is another reason not to call this > an "interface identifier." It's the MAC address of the interface out > which the DHCP packet was sent. In fact, it sounds like it's exactly the source MAC address of the packet as it was received by the relay agent. From greg.rabil@jagornet.com Fri Mar 30 11:32:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32E21F8628 for ; Fri, 30 Mar 2012 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmSF+WNvXKwb for ; Fri, 30 Mar 2012 11:32:50 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72A3F21F861D for ; Fri, 30 Mar 2012 11:32:50 -0700 (PDT) Received: by bkuw5 with SMTP id w5so907438bku.31 for ; Fri, 30 Mar 2012 11:32:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=nPeOFfrhfV2tC18lPlIAIsNukbU3C0FVdYUNvn1Eurg=; b=p4nvgAADdmGNqHlJbNJGDSSKPFHHCwC+6hoYCW6RHBSFeP7Ii4FYRh3UhKRiGrG1hJ B3OsBD8d06eqKr+nIhPDdNGna7DlHishNE5g+KS+fe9fV3ZmF7bEgHh3l5wgTtCSP8Jc iyGfPMxNrrujcGG3jixAzXeSNhhApZCOA73OSaNFd75bGcBH22qthnSaVcZlzBHVEvIE SH3NtpT2dAiJvAEHne3EfV8A+iUFISS855vOw3+uzXQXMivWNVGYVxqE8mGaAMg9Pjsv xA/b6nE5X5b9eetCe1/8HqVaXmG7OB7eLITf1FyDme5OXQC51U2dSUPSgA6GGqSWmgCW 4f4w== MIME-Version: 1.0 Received: by 10.205.137.15 with SMTP id im15mr1399825bkc.54.1333132367537; Fri, 30 Mar 2012 11:32:47 -0700 (PDT) Received: by 10.204.22.4 with HTTP; Fri, 30 Mar 2012 11:32:47 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D49C0@mbx-01.win.nominum.com> References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4986@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D49C0@mbx-01.win.nominum.com> Date: Fri, 30 Mar 2012 14:32:47 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon X-Gm-Message-State: ALoCoQlN1K7Bx+L0nJcx5ceRYL4p7XTWkLhErJNL8Xicn8wvOXfu1RNgknnKHox0HdRLT0vw1rDl Content-Type: multipart/alternative; boundary=000e0ce0f68e34a59b04bc7a1126 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 18:32:54 -0000 --000e0ce0f68e34a59b04bc7a1126 Content-Type: text/plain; charset=ISO-8859-1 I was considering the case where an administrator wants to configure it on DHCP server ahead of time. So, where they might know the MAC (because it was printed somewhere) of both interfaces, they probably don't know the IAIDs the device may choose for those interfaces, nor which IAID may correspond to which interface. I totally agree with you that from protocol standpoint, we have all that is needed to uniquely identify things (DUID+IAID+IA_type). From an administrative standpoint, however, I believe they need DUID+MAC to configure a truly unique static binding, because as you and others have pointed out, the MAC is not unique. Greg On Fri, Mar 30, 2012 at 11:12 AM, Ted Lemon wrote: > > If I want to assign a specific address to the wired interface and a > separate, specific address to the wireless interface, how do I know what > the IAID will be for each of them? > > You find out when you get a DHCP packet from each interface, and each > packet contains a DUID+IAID, and also contains the hardware address > (assuming that you already know which hardware address corresponds to which > interface). > --000e0ce0f68e34a59b04bc7a1126 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was considering the case where an administrator wants to configure i= t on DHCP server ahead of time. =A0So, where they might know the MAC (becau= se it was printed somewhere) of both interfaces, they probably don't kn= ow the IAIDs the device may choose for those interfaces, nor which IAID may= correspond to which interface. =A0I totally agree with you that from proto= col standpoint, we have all that is needed to uniquely identify things (DUI= D+IAID+IA_type). =A0From an administrative standpoint, however, I believe t= hey need DUID+MAC to configure a truly unique static binding, because as yo= u and others have pointed out, the MAC is not unique.

Greg

On Fri, Mar 30, 2012 at 11:12 AM, Ted Lemon = <Ted.Lemon@nominum.com> wrote:
> If I want to assign a specific address to the wired interface and= a separate, specific address to the wireless interface, how do I know what= the IAID will be for each of them?

You find out when you get a DHCP packet from each interface, and each= packet contains a DUID+IAID, and also contains the hardware address (assum= ing that you already know which hardware address corresponds to which inter= face).

--000e0ce0f68e34a59b04bc7a1126-- From Ted.Lemon@nominum.com Fri Mar 30 12:10:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E45C21F866B for ; Fri, 30 Mar 2012 12:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.185 X-Spam-Level: X-Spam-Status: No, score=-106.185 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94MCSHKETjbk for ; Fri, 30 Mar 2012 12:10:11 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id B118521F866A for ; Fri, 30 Mar 2012 12:10:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT3YFEjydtFcnD388+C8lra0GK9sCx80x@postini.com; Fri, 30 Mar 2012 12:10:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E8B0B1B80BA for ; Fri, 30 Mar 2012 12:10:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DD4C4190064; Fri, 30 Mar 2012 12:10:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 12:10:10 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] DUID+IAID Thread-Index: AQHNDk7f4FgtkXLiwESgwgUDJGkpD5aCkfCbgADC4wD//4tAkoAAeMQA//+VNoKAAHcfAP//jNrqABW23oD//5QDew== Date: Fri, 30 Mar 2012 19:10:08 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D5A6E@mbx-01.win.nominum.com> References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4986@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D49C0@mbx-01.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:10:11 -0000 Greg, this is getting exhausting. The MAC is not a unique identifier, eve= n for an individual client. Every request that comes out of an interface = will have the same MAC address under this proposal. This is true even if = more than one IAID is presented per interface. So identifying host interf= aces this way won't work. >From an administrative standpoint, you can use the mac to associate with th= e client in your administrative database or UI. You can use the mac to as= sociate DHCPv4 clients with a DHCPv6 client (notice the many-to-one mapping= here: a dual-stack device with two interfaces will appear to be two client= s to the DHCPv4 server). So the MAC address is useful, but it does not fit into the box you are tryi= ng to shoehorn it into here.