Subject: Re: [mobile-ip] 0.0.0.0 src address

From: Marc Hasson <[email-masked]>
Date: Mon, 3 Dec 2001 08:52:08 -0800 (PST)

Erik, Alper

 > Other protocols use 0.0.0.0 as a source. For instance, DHCPv4.
 > In that case the response it sent to 255.255.255.255 (and not 0.0.0.0)
 > unless I'm mistaken.

Correct.

I woke up this morning with the same thought (that 0.0.0.0 source is
responded to by broadcast in DHCPv4) and also remembered that in DHCPv4
its permissible/preferable to unicast the response to the
newly-assigned IP destination address using the DHCP client's
link-layer address.  0.0.0.0 does not appear in the IP destination
field in DHCPv4 in that case, however.  Its up to the DHCP'ing client
to request/accept either the broadcast response or the not-yet-heard-of
IP address as destination on the IP packet.  The broadcast option for a
DHCP server response was devised specifically for clients that would
otherwise drop a DHCP response with an IP destination that they don't
yet recognize as their own address-to-be.

It seems to me that a Mobile Node could accept its newly-assigned
non-zero unicast destination address just as well as the 0.0.0.0, it
should be well-aware its in an address discovery mode analagous to
DHCPv4 and process the UDP registration reply.

Following the DHCP model of doing the non-zero response would take care
of any RFC 1122 objection but I agree with Alper that this shouldn't be
a problem for new implementations to handle in either case (if there's
an objection to removing the 0.0.0.0 destination behavior thats already
out there).  Another way to resolve this, perhaps, would be to get a
dynamic/unique IPv4 link-local address first as I believe some
implementations do for non-mobility purposes.  But thats more
book-keeping for the MN and FA so is probably more complex than we want
to do to get around a 0.0.0.0 destination address.

I'm not aware of any specification, other than in this mobility draft,
where 0.0.0.0 is a valid unicast IP destination in a packet so it might
be nice to not have this sole exception but we can live with it if we
must.  Does anyone know of a non-mobility spec where this is already
used?

   -- Marc --

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 3 Dec 2001 13:16:45 -0800 (PST)

> DHCPv4 and process the UDP registration reply.

Is there any mobile node implementation which accepts UDP registration
reply destined to a newly assigned address and it's own link-layer
address while it sends the request with src-addr=0.0.0.0 ? 
As it was pointed out that it is possible for an implementation
to implement this behavior in MN.  
I think the mobile-ip base draft rfc2002-bis needs to clarify the
restriction on having src-addr = 0.0.0.0 and the consequent dst-addr
for the registration reply from FA to MN.

Note that it is also possible that FA may find that the registration 
request from  src-addr=0.0.0.0 and home-addr=0.0.0.0 is poorly-formatted
or some other problem, how does it reply back with error then ? ( Due to
the restriction in RFC1122 )
Should it drop the packet or send it to multicast addr ?

I wonder, why rfc2002-bis has a MUST in 3.6.1.1, could it be MAY ?

For example, what if any MN configures itself with a temporary address
to send the reg-req with home-addr=0, to get it's newly-assigned homeaddr? 

>    -  If the mobile node does not have a home address, the IP source
       address MUST be 0.0.0.0.

Also the draft needs to clarify that if the source-addr of the UDP registration
request is 0.0.0.0, then what will be the IP dst addr for the regReply.

-Samita

---

From: Marc Hasson <[email-masked]>
Date: Tue, 4 Dec 2001 10:33:57 -0800 (PST)

Samita,

(Sorry for the late response, @Home ate my own addressibility
yesterday. :-)   We'll see how my replacement cable company does
today...)

 > address while it sends the request with src-addr=0.0.0.0 ? 

Unknown.  This was just a suggestion on how to avoid the apparent 1122
commentary regarding destinations of 0.0.0.0 meaning the local machine as
opposed to something on the wire.

It seems to me that DHCP implementations (perhaps with kernel stack assist)
already handle this but I agree that mobile node implementations would not
unless we specified it.

 > to implement this behavior in MN.  

Agreed.  I have no problem with the functionality proposed for the 0.0.0.0
address, my only commentary has been that 2002bis seems to be the first
place where 0.0.0.0 appears as a destination unicast address in a packet.

 > for the registration reply from FA to MN.

100% agreed.

 > Should it drop the packet or send it to multicast addr ?

OK, good point there and perhaps I wasn't fully awake to think about
the error cases.  DHCP presumably responds with a broadcast "nak" and
lets the proper client figure it out based on the ids in the message.
The same could be done with the MN but this doesn't seem as "clean" to
me.  If it was important to avoid the apparent 1122 restriction then
thats what I would recommend but I think I'd agree that for
implementation simplicity the 0.0.0.0 handling is cleaner.

How are apparent conflicts with 1122 handled?  Just highlighted in 2002bis
since these are *mobile* host requirements, not plain hosts?

 > >    -  If the mobile node does not have a home address, the IP source

Yep, I found this confusing too.  I *think* the first MUST "overrides"
this second one when you have a co-located COA but I agree this should
be clarified.

 > request is 0.0.0.0, then what will be the IP dst addr for the regReply.

Yep.

   -- Marc --

---

From: "Lalwaney Poornima (NMP/SanDiego)" <[email-masked]>
Date: Wed, 5 Dec 2001 15:26:19 -0800

-----Original Message-----
From: ext Behcet Sarikaya [mailto:[email-masked]]
Sent: Wednesday, December 05, 2001 11:17 AM
To: [email-masked]
Subject: Re: [mobile-ip] 0.0.0.0 src address

Hello Lalwaley,

"Lalwaney Poornima (NMP/SanDiego)" wrote:

> Hi,
>
> As already discussed in this thread, the real problem is not with src=
> 0.0.0.0  but that if you follow RFC2002 by the word, there are cases
> where the destination IP agent advertisements and registration replies
> is copied from the src IP getting us to the scenario where destination
> IP=0.0.0.0. We have run into this issue with some implementations and
> have had interoperability concerns on this issue.

What kind of implementations of MIPv4 you are talking about? Hope you
can
share with us this info.

PL> Its Mobile IP over PPP as specified for CDMA2000, where the mobile
does not have an IP address at the end of the PPP ( As I understand it,
RFC2290 MIPv4 config option is not permitted for the temporary address
assignment which could have been a possible solution to avoid dest IP of
0.0.0.0). However, I expect that there are other networks and hosts
where the issue of destination IP = 0.0.0.0 when using dynamic home
adddress assignment will need to be addressed.

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 7 Dec 2001 16:41:28 -0800 (PST)

Hi Marc,
> implementation simplicity the 0.0.0.0 handling is cleaner.

IMHO, we need to stick to rfc1122 restriction--as it should not change for
mobileip draft.  Sending the reply to multicast or broadcast (when src-addr
is zero ) is reasonable.

> since these are *mobile* host requirements, not plain hosts?

This restriction in rfc1122 should be vaild in any kind of internet network.

> this second one when you have a co-located COA but I agree this should

From the discussion in the working group alias, it seems that folks agree
that MUST can be changed and the MN can use it's temporary ip-addr as
the source addr of the regReq while it requests for dynamic home-addr
assignment. Now we have to reach a consensus on sending replies to dst addr
(broadcast or multicast) when in fact the ip src-addr of the request is
zero. Thanks for your reply.

-Samita