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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 15 Oct 2006 10:51:32 -0400

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:[email-masked]] 
Sent: Friday, October 13, 2006 11:51 AM
To: [email-masked]
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.

[email-masked] 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>   

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 15 Oct 2006 10:52:30 -0400

Right. And just because it isn't useful to the DHCPv6 server, doesn't
mean it isn't useful to the router itself.

________________________________

From: Kostur, Andre [mailto:[email-masked]] 
Sent: Friday, October 13, 2006 12:16 PM
To: Anthony Baire; [email-masked]
Subject: RE: [dhcwg] [Question] When should we use Interface-ID option

> 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. 
> 
> Do people here actually use the Interface-Id option ? if yes, 
> which policy is used for assigning ipv6 addresses to the clients ? 

And this would be the point.  The DHCP RFCs are not intended to dictate
policy.  So other than suggesting that a DHCP server may use the
Interface ID for address assignment policy, it is not up to the DHCP
RFCs to say exactly how to do so.

Offhand, I'd envision some sort of mechanism where the DHCP server is
configured with the IPv6 address or DUID of the relay, and the Interface
IDs, and some list of prefixes associated with the DUID,IfID pair.