Subject: Re: [dhcwg] Question on Relay address field

From: Vijay Bhaskar A K <[email-masked]>
Date: Tue, 25 Sep 2001 01:21:04 +0530 (IST)

Jim,

Assume that my relay have the following configuration.

lan0  		-  fe80::260:b0ff:fec1:db08/10
lan0:1 		-  ff05::1:4:1/64
lan0:2		-  33fe:2900:1::1/64

lan2		-  fe80::1/10
lan2:1		-  1234::12/64

Please  note that,  whether the packet is received  in lan0:1 or lan0:2,
the stack returns the same interface  index.  (i.e) the interface  index
are same for all the logical interfaces like lan0:1, lan0:2,..

Using the IPV6_PKTINFO  option in setsockopt(), we can find out ONLY the
index of the  physical  interface.  We CANNOT  find out the exact  alias
interface  in which it is  received.  In other  words,  using the  index
returned by the  IPV6_PKTINFO,  we can find out, through  which card the
packet is  received.  We can find out whether it is received  in lan0 or
lan2.  But, we  cannot  find out  whether  it is  received  in lan0:1 or
lan0:2.  This is  because,  the IPv6  stack  assigns a single  interface
index for each physical interface.

Thus in our relay machine configuration...
index 1 corresponds to lan0 series. 
index 2 corresponds to lan2 series.

And the API, 
struct if_nameindex  *if_nameindex(void);
returns an array of if_nameindex as follows

if_index = 1
if_name  = lan0
if_index = 2
if_name  = lan2

Assume using  IPV6_PKTINFO, i am finding out the index as 1.  Then using
*if_nameindex(void)  i am finding out the interface name as "lan0".  But
the address  corresponds to the lan0 is  fe80::260:b0ff:fec1:db08/10  (a
link  local  address).  This  address  i SHOULD  not put it as the relay
address field.

Ok, lets us assume that, we will leave the link local  addresses  of the
physical interface, then, SHOULD i choose  ff05::1:4:1/64  (lan0:1) (or)
33fe:2900:1::1/64 (lan0:2)?

(or)  SHOULD i  choose  always  the  global  address  belonging  to that
physical interface?

If we decide that, we will choose always gloabal  address, what should i
do, if lan0 has 2 global  addresses of different  prefixes,  3ffe::20/16
and 5fee::20/64?  SHOULD i select first one or second one?

(or)  SHOULD i choose  the  first  configured  alias  interface  in that
physical interface?

Hope i have explained clearly abt the problem.

~Vijay

> Anil,
> 
> OK I get it.  Multiple issues here and they are not dhcp issues though.
> We in dhcp must assume you can get the interface address it came in on
> within an IPv6 implementation and thats not our job here to work that. But
> let me try to suggest how I would do it.
> 
> First assume you can get the interface index from 2292-bis or you do it on
> your implementation via some other means (sysctl/ioctl).  You then do an 
> if_nameindex() call to get all interface names from the base api not the
> advanced api.
> 
> 4.3 Return All Interface Names and Indexes
> 
> The if_nameindex structure holds the information about a single
> interface and is defined as a result of including the <net/if.h> header.
> 
>    struct if_nameindex {
>      unsigned int   if_index;  /* 1, 2, ... */
>      char          *if_name;   /* null terminated name: "le0", ... */
>    };
> 
> The final function returns an array of if_nameindex structures, one
> structure per interface.
> 
>    struct if_nameindex  *if_nameindex(void);
> 
> Then we would need to call our implementation defined functions to return
> each address for each interface name.
> 
> At this point the relay needs to use the proper scoping to get to the
> server.  Because we are embedding the address in the relay-forward option
> we must do what IPv6 will do with source address selection for sending IP
> packets in general which is select the proper scope for the relay-address.
> 
> I would argue until IPv6 scoping is more widely implemented and its not
> even been tested at our bake-offs for interoperability just yet the relay
> needs to configure a table for each interface at its node and depending on
> the scope of the server IP dst address select the best relay-address for
> that interface.  The default should be a global address for each address
> interface at the relay.
> 
> The other thing we can do is add to 2292-bis or build draft in ipng for
> extensiion to the base api to return all addresses to if_nameindex(). The
> base API is frozen and in the IEEE becoming standard now. So we cannot
> change that now or break existing production implementations.
> 
> But I do not think this systems programming implementation issue should
> affect the dhcp ipv6 standard at all and we should move forward. This is
> an API issue again not dhcpv6 protocol issue.
> 
> And we can all make this work.
> 
> My input to you.
> 
> /jim
> 
> 
> On Sat, 22 Sep 2001, Anil Kumar Reddy. S wrote:
> 
> > Hi Jim,
> > 
> >     As per IPv6 rfc2292bis (draft), through the socket option IPV6_RECVPKTINFO
> >     we can get the index of the interface through which the client packet is
> >     received. But the index will be same for all aliases and the
> >     primary address of the interface. So, if we get the interface index
> >     and try to get the address of that, then we get the link local address only
> > 
> >     because the primary address of an interface is always link local.
> >     (  Hope, I am clear in explaining   ;-))  )
> > 
> >     In this case, how the relay is expected to work, when an interface
> >     is configured with the addresses given by Vijay ?? Which address it has
> >     to consider ??
> > 
> > - Anil
> > 
> > Jim Bound wrote:
> > 
> > > Vijay,
> > >
> > > I am not clear why you can't tell the alias.  This will be a function of
> > > the scoping code for IPv6 as the interface in your example is using
> > > scoping (your aliases) and that is code that would have to be part of the
> > > base IPv6 stack to return from the API index routines?
> > >
> > > I am not clear this is a dhcp problem but an IPv6 implementation problem
> > > in general we all are working on now?
> > >
> > > Maybe I am missing your issue though?
> > >
> > > thanks
> > >
> > > /jim
> > >
> > > On Fri, 21 Sep 2001, Vijay Bhaskar A K wrote:
> > >
> > > > The latest draft on DHCPv6 says that, the client sends the
> > > > request to All Agents multicast address. The Agents put its
> > > > own address of the interface in which the client packet is
> > > > recieved, in the Relay-forward packet.
> > > >
> > > > Assume the configuration one of the interface of the Agent is as follows.
> > > >
> > > > lan0   -  A link local address
> > > > lan0:1 -  A site local address
> > > > lan0:2 -  A gloabal address
> > > >
> > > > Assume the packet is received from the client in the lan0 interface of the
> > > > agent.
> > > > Using our latest IPv6 APIs, we can identify this.
> > > > But, we CANT identify at what alias interface ( lan0 or lan0:1 or lan0:2)
> > > > in which the packet is received.
> > > >
> > > > Here the problem is, the relay cannot put its own link local address
> > > > in the relay address field in the relay forward packet, since this
> > > > info is useless.
> > > >
> > > > The question, SHOULD the relay put the address in lan0:1 (site local
> > > > address) or lan0:2 (global address)in the relay address field?
> > > > The DECISION of the relay is very important that depending up on the
> > > > address it is sending the relay address field only, the server can
> > > > allocate address to the client. Is there any solution to this
> > > > problem?
> > > > ~Vijay
> > > >

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Sep 2001 13:15:09 -0700

> interface  in which it is  received.

Packets are not received by interface aliases - they are received by
interfaces.   There is no way that IPV6_PKTINFO *could* tell you on
which alias interface a packet was received, because interface aliases
are not hardware - they are merely a logical construct that is used to
hang more than one address onto a single physical interface.

So there is no way to make the determination you're talking about - a
packet arrives on an interface, and any kind of processing you want to
apply to it beyond that has to be done in your software.

			       _MelloN_