RE: [dhcwg] dhcpv6-24: Interface-ID option

the one place we need to be careful with the interface ID is if the link-address is link-local from the client.  then the server has no clue regardless of the interface id. The server must look at the IP header from the relay to figure everything out.  

we should put the required scoped value of the address on the interface of the relay in the link address.  or else the relay now needs to maintain state to find the client.

I am not sure what the interface id is buying us but it is useful field for the future for sure I can think of many reasons such as a future partitioned IPv6 link.

/jim

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Wednesday, May 15, 2002 1:00 PM
> To: dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcpv6-24: Interface-ID option
> 
> 
> At 11:09 AM 5/8/2002 -0400, Thomas Narten wrote:
> > >    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 forwarded, the relay agent MUST include an Interface-id
> > >    option (see section 22.19) in the Relay-forward 
> message.  The server
> >
> >I think the interface-id option may be underspecified. If it is
> >included, but there is no valid link-address (which I understand is
> >the reason for defining this particular option), how does the server
> >know which addresses to assign the client? I.e., how does the server
> >know on which link the client is?
> 
> The relay agent always fills in the link-address field even 
> if it also 
> includes an Interface-id option.  Does the text need to be clarified?
> 
> 
> > >    The relay agent puts the client's address in the 
> link-address field
> > >    regardless of whether the relay agent includes an 
> Interface-id option
> > >    in the Relay-forward message.
> >
> >This doesn't seem right to me. I thought that the link-address is
> >supposed to hold the address of the relay agent. Seems wrong to put
> >the client's address in it. The link-address field is what the server
> >uses to figure out which link the client is on (right?). Also, since
> >the client's address is a link-local address, this field doesn't seem
> >to contain useful information for the server in this case.
> 
> This text should be edited to (based on suggested text from Bernie):
> 
>     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.
> 
> 
> > >    Servers MAY use the Interface-ID for parameter 
> assignment policies.
> > >    The Interface-ID SHOULD be considered an opaque value, 
> with policies
> > >    based on exact string match only; that is, the 
> Interface-ID SHOULD
> > >    NOT be internally parsed by the server.
> >
> >Shouldn't the first MAY be a MUST? I.e., the link-address field
> >contains no useful information.
> 
> The link-address field does contain useful information (a 
> site-scoped or 
> global address); the Interface-ID provides additional information.
> 
> >Also, not sure the above is sufficient. Unless the
> >interface-identifier is somehow stable, it's not clear how the server
> >policy could take it into account. There are no words suggesting the
> >interface-identifier needs to be stable.
> 
> OK, we'll add some words about stability.
> 
> 
> > >       interface-id         An opaque value of arbitrary 
> length generated
> > >                            by the relay agent to identify 
> one of the
> > >                            relay agent's interfaces
> >
> >Any reason not to make this 32 bits? the IPv6 API already has 32-bit
> >interface IDs. Is there any reason to make it larger?
> 
> The relay agent may use another value aside from the IPv6 API for the
> interface-id, so we should allow for arbitrary length.
> 
> - Ralph
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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