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

From: "Alper E. YEGIN" <[email-masked]>
Date: Sat, 1 Dec 2001 23:59:28 -0800

Siva,

> > The foreign agent should use the link-layer address of the incoming
(from
> > MN) packet
> > to send back the responds to the MN. So, FA can send a packet with
0.0.0.0
> > IP destination
> > address and MN's link-layer address as the destination MAC address.
> >
> > For that, foreign agent should note the source link-layer address of the
> > incoming packet.
> >
> > The same can also happen with simple rotuer discovery (sending router
> > solicitation, and
> > receiving router advertisement). Please see rfc1256.
>
> I agree with you regarding the usage of the link-layer address, which
> is standard means to forward replies to the MN. However, from the
> dicussions I have had with my "Transport" collegues regarding the
> usage of 0.0.0.0 as a dest address of a IP packet, it seems that:
>
>   The destination of 0.0.0.0 means "this machine on this network". So
>   by definition we CANNOT send a destination address of 0.0.0.0 onto
>   the network. This address is also used as a special address for DHCP
>   as a _source_ address. However it is not used as a destination.
>
> I was given RFC 1122 as a reference regarding the definition of
> the destination address 0.0.0.0.

Hmmm. I think I can explain how to implement this "sending to 0.0.0.0"
without causing problems (using link-layer address of the incoming packet),
but this still conflicts with the strict interpretation of RFC1122.

I think the strict interpretation of RFC1122 considers the case "sending to
0.0.0.0", not "sending to 0.0.0.0 where you know the link-layer address
of the destination".

>
> And for the same reason, an arp entry cannot be made at the FA to bind
> the MN's link-layer address to the IP address 0.0.0.0, which is
> required to forward the reply.....

A similar problem occurs when we have overlaping private addresses on the
same link. Two mobile nodes from two different domains can be using the
same home address (10.x.y.z). Yet, by looking at the which home agent is
sending the packets, the foreign agent can use the right link-layer
destination
address to forward them. This doesn't fit the arp table either. Also, I'm
guessing we can find a spec that says no two nodes can have the same
ip address on the same subnet.

>
>
> Am I still missing something here? :-)
>

I think you are right these are conflicting with earlier rfcs. But,
implementations can
handle them.

> thanks!
> Siva

alper

>
>
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Sivasundar Ramamurthy" <[email-masked]>
> > To: "Mobile IP Working Group" <[email-masked]>
> > Sent: Thursday, November 29, 2001 5:15 PM
> > Subject: [mobile-ip] 0.0.0.0 src address
> >
> >
> > > Hello,
> > >
> > > This is regarding draft rfc2002 bis-8 wrt using 0.0.0.0 as the IP
> > > source of registration requests. I have only recently joined this
> > > email group so please bear with me if this had been discussed earlier.
> > >
> > > Section 3.6.1.1 states that the Mobile Node must use 0.0.0.0 as the IP
> > > source address of the registration request if it does not have a home
> > > address. Section 3.7.2.3 states that the FA must use the
> > > IP source of the request as IP destination address when forwarding
> > > replies.
> > >
> > > Thus there might be cases where the FA must forward replies to the
> > > address 0.0.0.0. This task appears "impossible" since rfc1122 defines
> > > 0.0.0.0 as something like "this machine on this network", like
> > > loopback. So a packet with destination address 0.0.0.0 might never go
> > > out of the FA.
> > >
> > > Am I in the right here? Can someone please clarify the usage/handling
> > > of 0.0.0.0 as the source address of registration requests?
> > >
> > >
> > > Thanks in advance!
> > >
> > > Siva
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Dec 2001 15:49:55 +0100 (CET)

> 0.0.0.0", not "sending to 0.0.0.0 where you know the link-layer address

I think you're correct.

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.

   Erik