Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 19 Jul 2001 13:08:32 -0500

Oh ... one more point for consideration ...
 
If a client has multiple links and has received the "Server Unicast Option" from the server,
what's to prevent the client from sending the server a message out another interface (using
a prefix that the server has perhaps no knowledge of).
 
Or, the client might use a stateless autoconfigured address, again one the server has no
knowledge of since there's no reason to give the server this information.
 
Therefore when the server receives a message, it can NOT make ANY assumption about
the client's location based on the source address of the packet (unless it is a link local).
 
- Bernie

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Thursday, July 19, 2001 9:32 AM
To: DHCPv6 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

This probably won't add much since in the case of a Confirm, the client 
will likely be using its link-local address since that is the only one 
it can reliable use (well, except for others that it has obtained via 
stateless on the link). Thus, by definition, the client's Source IP 
address will be *valid*. 

If the client is unicasting a message to the server (hence it is likely 
using an address of greater scope than the link-local unless the server 
is on the link), the relay won't see it but the routers will and they 
would drop packets with invalid source addresses if they do egress 
filtering. 

In order for the relay to add valid, it would need to parse the client's 
message, find the addresses in the IAs, and check their prefixes. Hence, 
it is a bit of work. 

I don't think the relay requires any state to do this since it just needs 
to know the prefixes valid on that interface (which it should know either 
because it is the router OR because it can listen to Router Advertisements 
and learn them) and to parse the message. No state needs to be retained 
*BETWEEN* client messages. 

However, while there is some merit in allowing this, again, a server *MUST* 
also do it because it may be on-link with the client (hence no relay) or 
perhaps some relays will not chose to implement this. 

So, if we wanted to explicitly allow this relay behavoir, we could say 
that Relays *MAY* do this. In any case, servers *MUST* do it. 

I'm also wondering if there are cases where a DHCPv6 server might give out 
addressses that a relay has no knowledge of. For example, is there any 
prohibition against giving out IPv4 (mapped) addresses? [Perhaps these 
prefixes would also be advertised via Router Advertisements and thus we 
are OK.] 

- Bernie 

-----Original Message----- 
From: Vijay Bhaskar A K [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, July 19, 2001 5:54 AM 
To: DHCPv6 discussion list 
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

No, the relay need not to be stateful. It can just compare the 
prefix of Source IP address of the client packet and has to compare 
with the prefix of its interface in which it is received. It don't need 
to parse the packet. It has to just see the sender's address, that's all. 
But, this prevent the more and more processing that going to be 
happened on the servers. I think, including this functionality in the relay 
won't be a big problem. 
~Vijay 

> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ]On 
> Behalf Of Jim Bound 
> Sent: Thursday, July 19, 2001 10:18 AM 
> To: DHCPv6 discussion list 
> Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] 
> 
> 
> I think this is an option we can do later.  But I think we 
> are asking to 
> much of the relay.  The entire design goal has always been to keep the 
> relay as stateless as possible.  If the relay knows which prefixes are 
> good for a client and has to parse the addresses in a client packet I 
> think I am against that as one who has worked on building a 
> router this is 
> a bit intense.  In fact now that I think about it I think 
> this is simply 
> not a good idea. 
> 
> 
> /jim 
> 
> 
> On Wed, 18 Jul 2001, Ted Lemon wrote: 
> 
> > 
> > >   The format of "Error Code" option is not specified in 
> the draft. It is 
> > > needed to be included. 
> > 
> > I think it goes into the IA option, but you're right - it 
> needs to be 
> > clarified. 
> > 
> > >   It will be better, if this functionality can be 
> incorporated in the 
> > > agent,since, it is the only thing which knows well about 
> the prefix in which 
> > > the client message is received. And the advantage is, if 
> this checking is 
> > > done, this packet can be prevented from forwarding it to 
> the multiple 
> > > servers and save multiple processing time. The agent 
> itself can send the 
> > > NoPrefixMatch status directly to the client. 
> > 
> > Ooh, good point!   I think it would be good if the agent could do 
> > this, although I have to admit that I am concerned that some people 
> > who implement relay agents may not want to have to delve into the IA 
> > to validate a packet.   I'm in favor of doing as you suggest, but I 
> > suggest that we defer to the working group to see if any router 
> > vendors have a problem with this. 
> > 
> > Also, the timing is a bit tight on making this change, and 
> I wouldn't 
> > blame the authors if they said "no, sorry, do this in a new 
> draft."  I 
> > think it's okay to make this optional, so doing it in a 
> seperate draft 
> > should be fine. 
> > 
> > >   If the client is receiving the error status as 
> NoPrefixMatch error, what 
> > > may be the reason other than client's plugging in to 
> different subnet. I 
> > > agree that, some roghe server can send this status, but, 
> it can be prevented 
> > > by authentication. 
> > 
> > The client may be mobile, and may be able to reach more than one 
> > mobile access point.  The two access points may want to think of 
> > themselves as seperate links, even though their physical link-layers 
> > overlap.  I don't know how likely this is with existing technology, 
> > but it's certainly been discussed with respect to 3G 
> phones.  I think 
> > it's important to leave the language open for this case. 
> > 
> >                            _MelloN_ 
> > 
> 
>

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 21:25:02 -0400 (EDT)

if the server does not believe the src address of the client is valid then
it is not valid.  

/jim