Subject: RE: [mobile-ip] Issue with IPdst in FA reply when MN home address is 0.0.0.0

From: Matt Impett <[email-masked]>
Date: Fri, 5 Apr 2002 10:15:45 -0500

Snip from RFC 2131, section 4.1 "Constructing and Sending DHCP messages":

"Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER,
DHCPACK and DHCPNAK messages directly to the client using uicast delivery.
The IP destination address (in the IP header) is set to the DHCP 'yiaddr'
address and the link-layer destination address is set to the DHCP 'chaddr'
address."

As you can see, DHCP will actually try to send replies unicast to the
address that is being assigned, exactly how MIP is designed.  However, if
you read a little further in RFC 2131 (DHCP), it describes that some hosts
may not have the ability to receive IP packets sent to addresses they don't
yet have.  Therefore, they have built in a flag in the DHCPDISCOVER message
which requests that the server broadcast the replies back.

I don't really know if such hosts exist, but if so I guess they will not
work with MIP address assignment??

matt

> -----Original Message-----
> From: Steven M. Glass [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 8:37 PM
> To: [email-masked]
> Subject: [mobile-ip] Issue with IPdst in FA reply when MN home address
> is 0.0.0.0
> 
> 
>     As long as we're republishing 3220 anyway...
> 
>     The scenario in question is limited to a non-colocated MN 
> registering with
> a home address of 0.0.0.0 via a foreign agent.  In question 
> is the address the
> FA uses when sending a registration reply to said MN.
> 
>     My understanding of section 3.7.2.3 (and 3.7.3.2 which 
> refers to using the
> same rules as section 3.7.2.3) is:
> 
>         1) - FA rejecting the registration request ->
>             the registration reply is sent to 255.255.255.255
> 
>         2) - FA forwarding a registration reply from the HA ->
>             a) - if the registration reply contains a non-0 Home addr
>                  the FA forwards the reply to the [assigned] home addr
> 
>             b) - if the registration reply contains a home addr of
>                  0.0.0.0, the FA forwards the reply to 255.255.255.255
> 
>      If that's the correct understanding to have, then my 
> question is directed
> at 2a above:
> 
>      Why doesn't this behave like bootP, DHCP, etc, and 
> ALWAYS send the reply
> to 255.255.255.255?  Since in all cases the MN doesn't know 
> what address to
> listen for, making it consistent seems to me to be the right 
> thing to do.  I
> confess to having to read the section something like 3 times 
> to not mis-read
> it - so what am I missing?
> 
>                               Cheers,
>                                   Steve
>

---

From: "Steven M. Glass" <[email-masked]>
Date: Fri, 5 Apr 2002 14:09:06 -0500 (EST)

This is my concern (that and I like to see things more consistent across
related cases, and for easier implementation reasons).  I do NOT want to see a
bit in the registration request to indicate "please broadcast my registration
reply with an address assignment back to me".   My guess is the reason secion
3.7.2.3 is worded the way it is may have something to do with the misnomer
that broadcast@L3 means you broadcast@L2.  You can broadcast@L3 with a unicast
L2 (and thereby also not force your MN to support pomiscuity at L3).  One key
reason to not broadcast L2 is that it wakes sleeping clients (not nice if your
battery powered, smart radio management issues aside).

    Anyway, I'd like to see this changed so that the FA *always* sends
registration replies to 255.255.255.255 in response to registration requests
with IPsrc = 0.0.0.0.

    Does anyone else have any thoughts?

                              Cheers,
                                  Steve

---

From: kleung <[email-masked]>
Date: Tue, 09 Apr 2002 13:08:50 -0700

"Steven M. Glass" wrote:

> reply with an address assignment back to me".

Right.

> My guess is the reason secion

Right.

>     Does anyone else have any thoughts?

I agree. :)

Kent

---

From: "Steven M. Glass" <[email-masked]>
Date: Tue, 30 Apr 2002 17:18:14 -0400 (EDT)

The five opinions I've seen all agree with this - is that concensus?

                              Cheers,
                                  Steve

> related cases, and for easier implementation reasons).  I do NOT want to see
> a bit in the registration request to indicate "please broadcast my
> registration reply with an address assignment back to me".   My guess is the
> reason secion 3.7.2.3 is worded the way it is may have something to do with
> the misnomer that broadcast@L3 means you broadcast@L2.  You can broadcast@L3
> with a unicast L2 (and thereby also not force your MN to support pomiscuity
> at L3).  One key reason to not broadcast L2 is that it wakes sleeping
> clients (not nice if your battery powered, smart radio management issues
> aside).
>