RE: [dhcwg] Question on Relay address field

["Bernie Volz (EUD)" <[e-mail]>]

Note that recent changes for the -20 text address this in two ways:

1) The address given to the server is used to determine the link on which the client is located. This really (IMHO) should be a global address. But, I would recommend that relay implementors allow this to be set for a link (as to which address should be used). By default, I agree with Jim - use the/a global address.

2) If a relay needs specific information that it cannot communicate simply by supplying the address, we have added a relay option where it can pass the server anything it wants to use to identify how the relay needs to return the packet to the client. This information is sent back by the server in the Relay-Reply.

And, as Jim commented, this isn't really just a DHCP issue - it is more of a network issue in general. But if a particular implementation has a way to solve it, DHCPv6 is OK because it can be used to pass it on (such that the relay can return the reply).

- Bernie Volz

-----Original Message-----
From: Jim Bound [mailto:[e-mail]]
Sent: Saturday, September 22, 2001 12:53 PM
To: Anil Kumar Reddy. S
Cc: Dhcwg (E-mail)
Subject: Re: [dhcwg] Question on Relay address field


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
> > >
> > >
> > >
> > > ____Vijay_Bhaskar_A_K____
> > > ______Inet_Services______
> > > ________HP_ISO___________
> > > _____Phone:_2051424______
> > > ___Pager:_9624_371137____
> > >
> > >
> > > _______________________________________________
> > > dhcwg mailing list
> > > [e-mail]
> > > http://www1.ietf.org/mailman/listinfo/dhcwg
> > >
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > http://www1.ietf.org/mailman/listinfo/dhcwg
> 
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> |  Anil Kumar Reddy .S
> |  Senior Software Engineer,
> |  Hewlett-Packard,
> |  Bangalore, INDIA.
> |
> |  Telnet # 847-1426
> |  Ph. 2251554 Ext: 1426
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> 
> 


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