Achint Setia | 3 Dec 2004 06:20
Picon
Favicon

Relay Agent Options.


Hi,

I have a couple of doubts regarding the Relay Agent Options:-

1. What is the motive behind allowing the relay agent to add options
while     
   forwarding the client packet to the server? Are they to be used by
the     
   server in configuration selection for the client?

2. If yes, does that mean that when the server sends back the Relay
Reply,
   the ONLY TWO options that can be included are the Relay Message and
the    
   interface id.
   I am asking this because I am not sure as to how the relay agent will

   handle options other than these two in the Relay Reply?

Hope someone can clarify them.

Thanks,
Achint Setia.

 
Ralph Droms | 3 Dec 2004 06:28
Picon
Favicon

*DRAFT* minutes from dhc WG meeting in DC

Here are the draft minutes of the dhc WG meeting in DC.  Please review and
respond with comments by 1700 EST, Mon 2004-12-06

- Ralph Droms

-----

Administrivia                                      Ralph Droms

Droms asked about interest in DHCP server MIB,
draft-ietf-dhc-server-mib.  The specification has been reviewed by the
IESG and is close to being done.  However, one author is not
interested in continuing to work on the specification and the other
wants to confirm that there is sufficient interest before committing
to more work on the document.  Ted Lemon expressed interest in seeing
a server MIB (although not necessarily this one).  Droms will work
with Glen Waters (document co-author) to complete the specification.

Reclassifying DHCPv4 Options                       Bernie Volz

draft-ietf-dhc-reclassify-options is about to be published as an RFC.
Volz described the process for broadcasting notification of the
process specified in the document, and asked for assistance in
identifying all vendors whose use of option codes will be affected by
this specification.

DNS zone suffix option for DHCPv6                  Renxiang Yan
draft-yan-dhc-dhcpv6-opt-dnszone

Yan gave a presentation about draft-yan-dhc-dhcpv6-opt-dnszone.  The
(Continue reading)

Achint Setia | 3 Dec 2004 06:28
Picon
Favicon

DHCPv4 equivalent for DHCPv6 Options ?

Hi,

 

Is there any plan to have an equivalent RFC for DHCPv6 as RFC2132 defining various DHCPv4 options?

Are the DHCPv4 defined options to be supported in DHCPv6 in exactly the same manner (syntax and behavior)

as they were in v4.

 

Thanks,

Achint Setia.

 

 

 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
Achint Setia | 3 Dec 2004 06:41
Picon
Favicon

IPv6 Interface Identifiers.

I had this general doubt while reading the DHCPv6 RFC (3315).

 

When the addresses are assigned by a DHCPv6 server, the interface identifier will correspond to the one chosen

by the server from within its scope. This can be any number depending on how the scopes are defined at the server.

Doesn’t this contradict RFC 2373, which clearly states that the 64 bit Interface Identifier should be in EUI -64 format ?

Or does that mean the server needs to CONVERT the interface id, it has chosen, into the EUI-64 format before assigning it

to the client?

 

Thanks,

Achint Setia.

 

 

 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
Robert Elz | 3 Dec 2004 12:41
Picon

Re: IPv6 Interface Identifiers.

    Date:        Fri, 3 Dec 2004 13:41:22 +0800
    From:        "Achint Setia" <asetia <at> microsoft.com>
    Message-ID:  <91AC940D24F18041A3A68895289CE1EE012A5B45 <at> APS-MSG-02.southpacific.corp.microsoft.com>

  | Doesn't this contradict RFC 2373, which clearly states that the 64 bit
  | Interface Identifier should be in EUI -64 format ?

Perhaps, though a DHCP server could certainly generate addresses
that look as if they contain EUI-64 formatted interface identifiers
if it wants to - but almost anything sensible contradicts much of
what is in that part of RFC2373 - simply ignore it, the part of
2373 that is pretending to tell people what they should (must) be
using bits for inside their addigned address space is simply nonsense.

Use addresses however you want to use them, all that matters is
that the address chosen results in packets being delivered to the
correct system.

kre
Bernie Volz | 3 Dec 2004 15:16
Picon
Favicon

RE: Relay Agent Options.

Hi:

The motive is that there may be options similar to the DHCPv4 relay-agent
options that will be defined in the future. This might include subscriber
ID, remote agent ID, Radius options, etc. (I am planning to write up these
I-Ds but just haven't had the time yet.) Also, the relay agent can include
the vendor options (though RFC 3315 isn't that clear about that).

Presently, a server MUST send back the Interface-ID option and can ignore
any others (except of course for the Relay Message Option).

- Bernie

> -----Original Message-----
> From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] 
> On Behalf Of Achint Setia
> Sent: Friday, December 03, 2004 12:21 AM
> To: dhcwg <at> ietf.org
> Subject: [dhcwg] Relay Agent Options.
> 
> 
> 
> Hi,
> 
> I have a couple of doubts regarding the Relay Agent Options:-
> 
> 1. What is the motive behind allowing the relay agent to add options
> while     
>    forwarding the client packet to the server? Are they to be used by
> the     
>    server in configuration selection for the client?
> 
> 2. If yes, does that mean that when the server sends back the 
> Relay Reply,
>    the ONLY TWO options that can be included are the Relay Message and
> the    
>    interface id.
>    I am asking this because I am not sure as to how the relay 
> agent will
> 
>    handle options other than these two in the Relay Reply?
> 
> Hope someone can clarify them.
> 
> Thanks,
> Achint Setia.
>  
>  
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
Bernie Volz | 3 Dec 2004 15:26
Picon
Favicon

RE: IPv6 Interface Identifiers.

The DHCPv6 server can use the client's interface-identifier to addresses (by extracting it from the appropriate place - either from the source address or from the relay-agent's peer-address field if relayed). Or, the DHCPv6 server can other techniques to generate addresses, such as random numbers, perhaps using the RFC 3041 (or better yet, http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-01.txt).
 
- Bernie
-----Original Message-----
From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf Of Achint Setia
Sent: Friday, December 03, 2004 12:41 AM
To: dhcwg <at> ietf.org
Subject: [dhcwg] IPv6 Interface Identifiers.

I had this general doubt while reading the DHCPv6 RFC (3315).

 

When the addresses are assigned by a DHCPv6 server, the interface identifier will correspond to the one chosen

by the server from within its scope. This can be any number depending on how the scopes are defined at the server.

Doesn’t this contradict RFC 2373, which clearly states that the 64 bit Interface Identifier should be in EUI -64 format ?

Or does that mean the server needs to CONVERT the interface id, it has chosen, into the EUI-64 format before assigning it

to the client?

 

Thanks,

Achint Setia.

 

 

 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
Ralph Droms | 3 Dec 2004 15:28
Picon
Favicon

Re: Relay Agent Options.

Achint - I assume you're asking about DHCPv6?

Comments in line...

At 01:20 PM 12/3/2004 +0800, Achint Setia wrote:
>Hi,
>
>I have a couple of doubts regarding the Relay Agent Options:-
>
>1. What is the motive behind allowing the relay agent to add options
>    while forwarding the client packet to the server? Are they to be
>    used by the server in configuration selection for the client?

Relay agent options may be used by the server in determining the
configuration of the client or by the relay agent to aid in forwarding the
response from the server to the client (see RFC 3046).

>2. If yes, does that mean that when the server sends back the Relay
>    Reply, the ONLY TWO options that can be included are the Relay
>    Message and the interface id.  I am asking this because I am not
>    sure as to how the relay agent will
>    handle options other than these two in the Relay Reply?

The Relay-reply message contains the message to be forwarded to the client,
and any other options that the server is sending to the relay agent.  See
section 22.10 of RFC 3315 for more detail on the contents of the Relay-reply
message, and sections A and B of RFC 3315 for a table of which options can
appear in which messages.

>Hope someone can clarify them.
>
>Thanks,
>Achint Setia.

- Ralph Droms
Ralph Droms | 3 Dec 2004 15:33
Picon
Favicon

Re: DHCPv4 equivalent for DHCPv6 Options ?

Achint - comments in line...

At 01:28 PM 12/3/2004 +0800, Achint Setia wrote:

>Hi,
>
>Is there any plan to have an equivalent RFC for DHCPv6 as RFC2132 defining 
>various DHCPv4 options?

No.  The options defined with the original specification of DHCPv6 are in
RFC 3315 rather than a separate RFC.  New options will be specified in
separate RFCs.  We wrote a separate RFC for DHCPv4 options because there
were many more options defined at the time RFCs 2131 and RFC 2132 were
published.

>Are the DHCPv4 defined options to be supported in DHCPv6 in exactly the 
>same manner (syntax and behavior)
>as they were in v4.

No.  The dhc WG considered but rejected a plan to carry forward the
definition of all of the DHCPv4 options to DHCPv6.  Instead, we adopted the
strategy of defining new options as requirements for those options are
identified.

>Thanks,
>
>Achint Setia.

- Ralph Droms
Bernie Volz | 3 Dec 2004 15:22
Picon
Favicon

RE: DHCPv4 equivalent for DHCPv6 Options ?

Is there any plan to have an equivalent RFC for DHCPv6 as RFC2132 defining various DHCPv4 options?

 
No, there are RFCs and I-Ds that will define DHCPv6 options. See http://www.iana.org/assignments/dhcpv6-parameters for the official list of assigned DHCPv6 option numbers and references to the RFCs that define them. For work in progress, best to see http://www.ietf.org/html.charters/dhc-charter.html.
 
Are the DHCPv4 defined options to be supported in DHCPv6 in exactly the same manner (syntax and behavior) as they were in v4.
 
No. We decided early on that we wanted a clean slate. Therefore, if there are options from DHCPv4 that are desired in DHCPv6, someone needs to write an Internet-Draft and get it to an RFC.
 
If there are vendor specific options, use the OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS options.
 
- Bernie
-----Original Message-----
From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf Of Achint Setia
Sent: Friday, December 03, 2004 12:29 AM
To: dhcwg <at> ietf.org
Subject: [dhcwg] DHCPv4 equivalent for DHCPv6 Options ?

Hi,

 

Is there any plan to have an equivalent RFC for DHCPv6 as RFC2132 defining various DHCPv4 options?

Are the DHCPv4 defined options to be supported in DHCPv6 in exactly the same manner (syntax and behavior)

as they were in v4.

 

Thanks,

Achint Setia.

 

 

 

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

Gmane