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

["Bernie Volz \(volz\)" <volz at cisco.com>]

While I think it will be rare for the interface-id option to be used for
assigning addresses, it could be used.

For example, suppose you are an ISP and have a router (which is also a
relay agent) somewhere on your network and you have customers connected
to that router. As specific customers are hard-wired to a particular
port (interface id) and the ISP has no knowledge of the customer's
device behind that port (hence the client-id is not useful), you might
well want the same port to always get the same address (or more likely
the same delegated prefix).

Now, you could do that by configuring the link-address to be used for
each port on the router, but you could also do it by configuring the
DHCPv6 server with the link-address (identifies the router/relay) and
interface-id option.

Ideally, something like the remote-id option (RFC 4649) is more useful
since that encapsulates both the physical router (relay) identity *AND*
the port. But, your relay may not yet implement the remote-id option.

---

And, even if the server never uses the interface-id, it can be of
significant value to the router (as my previous post on this subject
outlines).

- Bernie

-----Original Message-----
From: Anthony Baire [mailto:abaire at irisa.fr] 
Sent: Friday, October 13, 2006 11:51 AM
To: dhcwg at ietf.org
Subject: Re: [dhcwg] [Question] When should we use Interface-ID option

Hi Hideshi and all,


I am also wondering how the Interface-Id field should be used
practically.

RFC3315 is quite clear about how to use it for routing Relay-Reply
messages back to the client. But the rfc is evasive about how to use it
in practice, especially how to integrate it into the address assignment
process.

RFC3315 says servers can use the link-address field for identifying to
which link the client is attached so as to assign a suitable ipv6
address. However when a relay-forward message carries an Interface-Id
option, the link-address field is undefined[1]  but the server may still
process it. The outcome is undefined and the rfc does not address this
issue.

What do others think about this ?

Do people here actually use the Interface-Id option ? if yes, which
policy is used for assigning ipv6 addresses to the clients ?


Regards

--
Anthony Baire
INRIA/IRISA - ARMOR Project

[1]  as it is suggested in your message: rfc says the field must be
filled but does not say which value should be used.



Hideshi.Enokihara at jp.yokogawa.com wrote:
> 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
>   


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

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