[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] [Question] When should we use Interface-ID option



Thank you for a detailed answer. 

I could understand that Interface-ID option usage situation.

I'm working for making up the IPv6 Ready Logo specification for DHCPv6 Logo.
IPv6 Ready Logo : http://www.ipv6ready.org/frames.html
And I am considering whether Interface-ID should be covered by DHCPv6 Logo test specification.

So, I wanted to know in what situation the Interface-ID option was required.
I can figure out that it depend on the structure of Relay Agant(Router).
Is my understanding right?

If so, how much is proportion of such Relay Agent(Router)s?
If such Relay Agents are rare case, I would not cover Interface-ID option by DHCPv6 Logo test specification.

Thank you for your help every time!

Best regards,

On Tue, 17 Oct 2006 12:13:47 -0400
"Bernie Volz (volz)" <volz at cisco.com> wrote:

> The following picture is more what I had in mind;
> 
> 
> ------------------
>       DHCPv6 Server
>            |
>            |
>   ---------+---------+--------
>                      | 
>                      | Relay has one Global Address
>                 +----+--------------+
>                 |Relay Agent(Router)|
>                 +----+----+----+----+
>                      |    |    |
>                      VC   VC   VC
>                      |    |    |
>                      +----+----+------ PC
> 
> Where VC is virtual circuit and PC is physical circuit. (Note that the
> VCs are really INSIDE the Router and not physical wires coming out of
> the box.) Take X.25 or ISDN, these have VCs and PCs.
> 
> So, the Interface-ID may well identify that the client's packet came
> from a VC and it came from VC X.
> 
> 
> >Is Interface-ID option often used by current state (In other words,
> does
> >this option have important role in current DHCPv6 circumstance? )?
> >Moreover, when we think about future DHCPv6 usage, will this option
> play
> >a big role?
> 
> If you are asking "Will relay agents send the Interface-ID and expect it
> to be echoed back in server responses", I would say **YES**.
> 
> If you are asking "Will servers use the Interface-ID for address
> assignment or prefix delegation", I would say maybe.
> 
> I'm not sure what you're driving at.
> 
> The bottom line is (per RFC 3315, section 22.18):
> 
> * A DHCPv6 server is required to echo it back to the relay agent (if
> sent by a relay agent):
> 
>    The server MUST copy the Interface-Id option from the Relay-Forward
>    message into the Relay-Reply message the server sends to the relay
>    agent in response to the Relay-Forward message.  This option MUST NOT
>    appear in any message except a Relay-Forward or Relay-Reply message.
> 
> * A DHCPv6 server is NOT required to provide it as a way to assign
> addresses or delegate a specific prefix:
> 
>    Servers MAY use the Interface-ID for parameter assignment policies.
>    The Interface-ID SHOULD be considered an opaque value, with policies
>    based on exact match only; that is, the Interface-ID SHOULD NOT be
>    internally parsed by the server.  The Interface-ID value for an
>    interface SHOULD be stable and remain unchanged, for example, after
>    the relay agent is restarted; if the Interface-ID changes, a server
>    will not be able to use it reliably in parameter assignment policies.
> 
> * A Relay Agent is NOT required to send it:
> 
>    The relay agent MAY send the Interface-id option to identify the
>    interface on which the client message was received.  If a relay agent
>    receives a Relay-reply message with an Interface-id option, the relay
>    agent relays the message to the client through the interface
>    identified by the option.
> 
> So, if you're building a server, you can decide whether you want to
> offer it in terms of assignment policies. And, if you're building a
> relay, you can decide whether the relay needs the option for a specific
> purpose.
> 
> - Bernie
> 
> -----Original Message-----
> From: Hideshi.Enokihara at jp.yokogawa.com
> [mailto:Hideshi.Enokihara at jp.yokogawa.com] 
> Sent: Tuesday, October 17, 2006 7:24 AM
> To: Bernie Volz (volz)
> Cc: dhcwg at ietf.org
> Subject: RE: [dhcwg] [Question] When should we use Interface-ID option
> 
> Dear Bernie Volz,
> 
> Thank you very much for your reply.
> 
> But, I couldn't understand the words "a bunch of circuits". 
> Sorry for my deficient knowledge. 
> Is "a bunch of circuits"  like below situation?
> 
> ------------------
>       DHCPv6 Server
>            |
>            |
>   ---------+---------+--------
>                      | 
>                      | Relay has one Global Address
>                 +----+--------------+
>                 |Relay Agent(Router)|
>                 +----+----+----+----+
>                      |    |    |
>                      CL   CL   CL
> -------------------
> Are these CLs off-link each other?
> Or on-link?
> 
> One more question.
> Does the situation of "a bunch of circuits" that you mentioned in the
> previous email often appear in  Address Assignment?
> How about in Other configuration and Stateless DHCPv6?
> 
> What do you think regarding Interface-ID option?
> Is Interface-ID option often used by current state (In other words, does
> this option have important role in current DHCPv6 circumstance? )?
> Moreover, when we think about future DHCPv6 usage, will this option play
> a big role?
> 
> I'm sorry to bother you.
> 
> Best regards,
> > -----Original Message-----
> > From: Bernie Volz (volz) [mailto:volz at cisco.com] 
> > Sent: Sunday, October 15, 2006 11:44 PM
> > To: Enokihara, Hideshi (Hideshi.Enokihara at jp.yokogawa.com); 
> > dhcwg at ietf.org
> > Subject: RE: [dhcwg] [Question] When should we use Interface-ID option
> > 
> > Hideshi:
> > 
> > If a relay agent (which is a router) terminates a bunch of 
> > circuits, it may well be that each of those circuits does not 
> > have their own unique prefix (and hence a link-addess field 
> > that can be used). For example, a relay may have one global 
> > address for all of these circuits.
> > 
> > In such a case, the relay must know on which circuit to relay 
> > any replies from a server, and hence the interface-id can be used.
> > 
> > - Bernie
> > 
> > -----Original Message-----
> > From: Hideshi.Enokihara at jp.yokogawa.com
> > [mailto:Hideshi.Enokihara at jp.yokogawa.com]
> > Sent: Friday, October 06, 2006 3:43 AM
> > To: dhcwg at ietf.org
> > Subject: [dhcwg] [Question] When should we use Interface-ID option
> > 
> > Hi all,
> > 
> > I have a question regarding Interface-ID option in DHCPv6.
> > 
> > RFC3315 defines Interface-ID option,
> > but I cannot understand in what situation this option should be used. 
> > 
> > RFC3315 20.1.1 says,
> > ----------
> > (snip)
> >    If the relay agent cannot use the address in the link-address field
> >    to identify the interface through which the response to the client
> >    will be relayed, the relay agent MUST include an 
> > Interface-id option
> >    (see section 22.18)
> > (snip)
> > ----------
> > 
> > I cannot imagine above sentence situation.
> > I mean that I can't think up the situation("Relay agent 
> > cannot use the address in the link-address field to identify 
> > the interface")
> > 
> > Someone, please teach me the situation that Relay agent 
> > should use Interface-ID option in detail.
> > 
> > Moreover, I can't understand actual meaning of following statement.
> > #I feel the RFC is unclear regarding Interface-id option usage.
> > --------------
> > 20.1.1. Relaying a Message from a Client
> >    (snip)	
> >  
> >                                                               
> >        The
> >    relay agent fills in the link-address field as described in the
> >    previous paragraph regardless of whether the relay agent 
> > includes an
> >    Interface-id option in the Relay-forward message.
> > ---------------
> > In this statement, when a Relay agent includes an 
> > Interface-id option, what should the Relay agent fill in the 
> > link-address field?
> > 
> > What do you think?
> > 
> > Best Regards,
> > 
> > *************************************
> > Hideshi Enokihara
> > IPv6 Business
> > Network & Software Development Dept.
> > Yokogawa Electric Corporation
> > 
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 


-- 
*************************************
Hideshi Enokihara
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation

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