Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI

From: Mohamed Khalil <[email-masked]>
Date: Mon, 3 Jan 2000 14:20:17 -0600

Hi Pete,

I think the correct and clean way to allow any user to have multiple devices
is to have each device owned by a user to send a new extension during the
registration phase called a  Device Extension. This extension may be
attached to both registration request and reply. The home agent will use the
device id to allocate a mobile device an IP address when it is necessary.

 0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type            |      sub-type          |      length
|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            device parameters .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            device id .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type            Generic Device extension type (TBD)

    length         The length of the NAI-INFO field.

    Sub-Type       1   ETHERNET_DEV.
                         2   TDMA_DEV.
                         3   CDMA_DEV.

    device parameters  this section defines the device parameters
                       which is requested by the mobile node. this
                       section MAY be modified by the home agent
                       or foreign agent to match the current operating
                       capability of the network and the services
                       which is allowed for the user. The structure
                       of this section depends on the type of the device.

   device id  It is the device identification.

              example MCI-LAPTOP-193.193.193.20

> -----Original Message-----
> From: Pete McCann [SMTP:[email-masked]]
> Sent: Monday, January 03, 2000 1:26 PM
> To:   [email-masked]
> Subject:      Re: [MOBILE-IP] Multiple IP addresses per NAI
>
> Hi, Kent,
>
> "Kent K. Leung" <[email-masked]> (KKL) writes:
>
> >> Maybe the Identification field can play this role, so we don't need to
> >> do any new protocol specification.  Things could work this way: a
> >> Registration Request that already has an IP home address does not get
> >> allocated a new one.  Any Registration Request that is missing a home
> >> address and has a unique Identification field does get allocated a new
> >> address.  Retransmissions of the same Request with the same
> Identification
> >> get the same address.
>
> KKL> But this doesn't work for re-registration by the same MN.  How can
> KKL> a HA differentiate between an MN that's doing re-registration vs.
> KKL> MN registering another device?
>
> Re-registrations will presumably have valid Home Address fields in the
> registration request.  New registrations will have 0.0.0.0.
>
> >> Maybe there are some pathological conditions involving lost Replies
> >> that would cause addresses to be used up unnecessarily - for instance,
> >> if a Reply is lost, the MN might retransmit a request with a new
> >> Identification value and accidentally get a second address without
> >> ever knowing about the first.  But the old address would time out
> >> after the Lifetime expired anyway, so maybe it's not such a problem.
>
> KKL> This scenario also exhaust addresses unnecessarily.  The expiration
> KKL> of the leased address depends on the registration lifetime, which
> KKL> may be long.
>
> You may be right.
>
> KKL> IMHO, I don't think using the Identification field is sufficient.
>
> Maybe so, but I don't think we should necessarily augment the NAI
> extension itself - that would slow down too many other efforts.  Maybe
> a new Session ID extension should be created.
>
> -Pete

---

From: "Kent K. Leung" <[email-masked]>
Date: Mon, 3 Jan 2000 12:50:00 -0800

> registration phase called a  Device Extension. This extension may be

I agree with this approach.

> > registration request.  New registrations will have 0.0.0.0.

I think part of the problem is that address allocation has not been
sufficiently covered by any drafts.  The NAI draft does not explain
the meaning when NAI extension exist and home address is non-zero.
Does this always happen for re-registrations?   Re-registrations
may have zero home address field.

My interpretation is that the HA could use this ip address as a hint
for address allocation even for new registrations (similar to dial
environment).  But if address is used, then HA will return a new ip
address.  But some maybe the MN really wanted that address for some
reason.  In that case, MN should deregister that address after being
accepted.  Anyways, it's ambiguous on how HA deal with registrations
with NAI ext and non-zero Home Address.

> > a new Session ID extension should be created.

I don't have problem with that.  Not all cases require further
NAI subidentification.

-- Kent --

---

From: Pete McCann <[email-masked]>
Date: Tue, 4 Jan 2000 14:49:04 -0600

Hi, Kent,

>> registration phase called a  Device Extension. This extension may be

KKL> I agree with this approach.

But what about a mobile device with two different interfaces of two
different technologies - wouldn't it be nice to be able to continue a
session from, say, CDMA to Ethernet?  I don't think we need to pin
down the device's link-layer address (maybe Mohamed's extension
doesn't quite do that, but it at least gives the specific technology.
This may preclude handoff from one technology to another).  A logical
session identifier seems more appropriate.  This could just be a
single (small) integer, and it should be independent of the
link-layer technology in use.

>> > registration request.  New registrations will have 0.0.0.0.

KKL> I think part of the problem is that address allocation has not been
KKL> sufficiently covered by any drafts.  The NAI draft does not explain
KKL> the meaning when NAI extension exist and home address is non-zero.
KKL> Does this always happen for re-registrations?   Re-registrations
KKL> may have zero home address field.

KKL> My interpretation is that the HA could use this ip address as a hint
KKL> for address allocation even for new registrations (similar to dial
KKL> environment).  But if address is used, then HA will return a new ip
KKL> address.  But some maybe the MN really wanted that address for some
KKL> reason.  In that case, MN should deregister that address after being
KKL> accepted.  Anyways, it's ambiguous on how HA deal with registrations
KKL> with NAI ext and non-zero Home Address.

Perhaps whatever new extension is defined could clarify these issues.
My feeling is that if the MN gives an address, it expects to have that
address assigned to it.  We need to preserve compatibility with nodes
that don't do dynamic address assignment.

>> > a new Session ID extension should be created.

KKL> I don't have problem with that.  Not all cases require further
KKL> NAI subidentification.

-Pete

---

From: "Kent K. Leung" <[email-masked]>
Date: Tue, 4 Jan 2000 13:43:30 -0800

Hi Pete.

> link-layer technology in use.

I agreed with the general approach of having a sub-NAI extension.
Actually, I was thinking along the line that the extension would
just contain Type-Length-Value where Value is defined by
NAI's username grammar (in RFC 2486).  This provides some
flexibility.

> that don't do dynamic address assignment.

Yes, it needs clarification.  A node that doesn't do dynamic address
assignment can still deal with the reply properly.  But the scheme
allows for nodes to say "I prefer this address, but give me any if
that's not available" as well.  Since the sub-NAI extension deals
with address allocation, the draft should clarify
ambiguities that will cause interoperability.

-- Kent --