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

From: "Steven M. Glass" <[email-masked]>
Date: Thu, 4 Apr 2002 20:36:36 -0500 (EST)

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: Samita Chakrabarti <[email-masked]>
Date: Tue, 9 Apr 2002 11:38:47 -0700 (PDT)

>     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
> 
> 
>

There was a mailing list discussion before SLC meeting regarding the topic when
source address of the registration request is zero. As per that discussion,
the question was whether the src addr of a MN MUST be 0.0.0.0 when it does not
have a home-addr. Many discussion participants thought that
there was no need that MN must use 0.0.0.0 source address. So the request
was to change MUST to MAY or SHOULD. (note: MN may use any temporary address
while asking for it's home address via NAI).

section 3.6.1.1 in RFC3220 states:

3.6.1.1. IP Fields

   This section provides the specific rules by which mobile nodes pick
   values for the IP header fields of a Registration Request.

   IP Source Address:

      -  When registering on a foreign network with a co-located care-of
         address, the IP source address MUST be the care-of address.

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

      -  In all other circumstances, the IP source address MUST be the
         mobile node's home address.

My question is if we mostly agree on the 'MUST' part of the second bullet item ?
Does it make sense to change it to MAY or SHOULD ?

Next, as it was already brought up that section 3.7.2.3 needs clarification.
There is actually a conflict between section section 3.4 destination address
of IP header of RegReply field and dst addr described in section 3.7.2.3.

Section 3.4 states:
     Destination Address  Copied from the source address of the
                           Registration Request to which the agent is
                           replying

Section 3.7.2.3 says:

     IP Destination Address

               If the Registration Reply is generated by the Foreign
               Agent in order to reject a mobile node's Registration
               Request, and the Registration Request contains a Home
               Address which is not 0.0.0.0, then the IP Destination
               Address is copied from the Home Address field of the
               Registration Request.  Otherwise, if the Registration
               Reply is received from the Home Agent, and contains a
               Home Address which is not 0.0.0.0, then the IP
               Destination Address is copied from the Home Address field
               of the Registration Reply.  Otherwise, the IP Destination
               Address of the Registration Reply is set to be
               255.255.255.255.

Again,

3.7.3.2. Forwarding Replies to the Mobile Node

 Specific fields within the IP header and the UDP header of the
   relayed Registration Reply are set according to the same rules
   specified in Section 3.7.2.3.

So, I think, this gives an impression that the destination address of
the RegReply to MN should always be set to the homeaddr field copied from
the RegReply from HA. 

Note, that section 3.4 states the destination addr of IP header correctly.

The destination addr of RegReply to MN should be set to the source address
of the registration request (when source-addr of the reg-req is non-zero).
Otherwise, an implementation may need to hack IP layer unncessarily to receive
reply packets to a home-addr even though it's interface is not configured
for it. The current description in 3.7.2.3 will also pose problem for MN
when  it has to register through FA due to 'R' bit advertisement, i,e. 
source addr of MN (section 3.6.1.1):
-  When registering on a foreign network with a co-located care-of
         address, the IP source address MUST be the care-of address.

Would the following text for section 3.7.2.3 fix the inconsitencies ?

     IP Destination Address

               If the Registration Reply is generated by the Foreign
               Agent in order to reject a mobile node's Registration
               Request, and the Registration Request contains a source 
               Address which is not 0.0.0.0, then the IP Destination
               Address is copied from the IP source address field of the
               Registration Request.  If the Registration
               Reply is received from the Home Agent, and the corresponding
            Registration Request contains a non-zero source address, then theIP
               Destination Address is copied from the source address field
               of the Registration Request.  Otherwise, when the source address
               of the Registration request is 0.0.0.0 the IP Destination
               Address of the Registration Reply is set to be 255.255.255.255.

The above text should cover the following scenarios:

1. When MN has home-addr as it's configured IP-addr
2. When MN has Co-located care-of-addr.
3. When MN has configured with home-addr, but the HA replied with
   a home-addr which is not equal to the currently configured one.
4. When MN does not have any IP address configured and uses 0.0.0.0
   as it's source address of the registration request.
5. When MN does not have a home-addr, but acquires a temporary address
   in the local network and requests a homeaddr from homeagent (If
   we allow this case, actually this case is useful to prevent broadcast
   regReply, even though the L2addr could be the unicast one, but don't
   know if there is any security threat behind this). 

-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 30 Apr 2002 14:59:02 -0700 (PDT)

Hi Steve,

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

I have suggested  the following text for 3.7.2.3 to fix the problems 
in the RFC3220, as per Charlie's request. Did not hear any objection
to it so far. So, I believe, we can use this text.

     IP Destination Address

Also, in my previous email, I had requested to revisit the 'MUST' requirement

for IP Source address in 3.6.1.1 section as per previous email discussions
in the list:

   IP Source Address (as per current definition in RFC3220):

> >     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).
> > 
> > > 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
> > > > 
> > > >