Subject: [dhcwg] Question on Relay address field

From: "Vijay Bhaskar A K" <[email-masked]>
Date: Fri, 21 Sep 2001 11:54:09 +0530

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

____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
_____Phone:_2051424______
___Pager:_9624_371137____

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

---

From: Jim Bound <[email-masked]>
Date: Fri, 21 Sep 2001 23:51:09 -0400 (EDT)

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

---

From: "Anil Kumar Reddy. S" <[email-masked]>
Date: Sat, 22 Sep 2001 18:33:46 +0530

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

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|  Anil Kumar Reddy .S
|  Senior Software Engineer,
|  Hewlett-Packard,
|  Bangalore, INDIA.
|
|  Telnet # 847-1426
|  Ph. 2251554 Ext: 1426
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

---

From: Jim Bound <[email-masked]>
Date: Sat, 22 Sep 2001 12:52:53 -0400 (EDT)

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