Subject: Re: [mobile-ip] Mobile IPv6 draft revision

From: Alper Yegin <[email-masked]>
Date: Thu, 23 Aug 2001 17:31:42 -0700 (PDT)

Charlie,

I assume the "Connectathon 2001 feedback on the Mobile IPv6 draft" will also be 
incorporated into this upcoming version. Right? I attached the original e-mail 
that details the issues which were both presented at IETF 50 and sent on the 
mailing list before.

Regards,

alper

> Hello folks,
> 
> Following the recent discussion, I believe a new revision to the
> existing Mobile IPv6 draft ...-14 is needed.  The new draft would
> have the following features:
> 
> - Removal of all text related to Mobile Routers, including the
>   'R' bit of the Binding Update
> 
> - Reorganizing the Binding Update format so that:
>   = authentication data is able to be included as a suboption
>   = Specify that the Binding Update needs a new header number
>   = Specify that the Binding Update must follow AH whenever
>     AH is present.
>   This will allow use of AH in the future, but allow the use
>   of other authentication algorithms which can be specified
>   directly to depend on specialized key exchange protocols
>   as has been discussed recently.
> 
> - other minor fixes that have been reported.
> 
> I believe these fixes conform to recent consensus, do not
> represent a significant upheaval to existing implementations,
> and may help to make future discussion more productive.
> 
> Comments?
> 
> Regards,
> Charlie P.

alper

Subject: Message from mail server
From: Postmaster
Date: Thu, 23 Aug 2001 17:29:58 -0700 (PDT)

Delete.
This is a system message.                                

--END+PSEUDO--

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 23 Aug 2001 17:53:24 -0700

Hello Alper,

Yes, and thank you very much for the reminder!

Regards,
Charlie P.

Alper Yegin wrote:

>   ------------------------------------------------------------------------
>
> >From [email-masked]  Mon Jul 16 18:05:22 2001
> X-Unix-From: [email-masked]  Mon Jul 16 18:05:22 2001
> Received: from engmail3.Eng.Sun.COM (engmail3.Eng.Sun.COM [129.144.170.5])
>         by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6H15Mb895428;
>         Mon, 16 Jul 2001 18:05:22 -0700 (PDT)
> Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
>         by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03333;
>         Mon, 16 Jul 2001 18:05:12 -0700 (PDT)
> Received: (from majordomo@localhost)
>         by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6H14Ex22313
>         for mobile-ip-dist; Mon, 16 Jul 2001 18:04:14 -0700 (PDT)
> Received: from jurassic.eng.sun.com (jurassic [129.146.88.31])
>         by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6H14AN22306
>         for <[email-masked]>; Mon, 16 Jul 2001 18:04:10 -0700 (PDT)
> Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247])
>         by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with SMTP id f6H14Ib894290;
>         Mon, 16 Jul 2001 18:04:18 -0700 (PDT)
> Message-Id: <[email-masked]>
> Date: Mon, 16 Jul 2001 18:04:23 -0700 (PDT)
> From: Alper Yegin <[email-masked]>
> Subject: Re: [mobile-ip] draft-ietf-mobileip-ipv6-14.txt
> To: [email-masked], [email-masked]
> MIME-Version: 1.0
> Content-Type: MULTIPART/mixed; BOUNDARY=Caravan_of_Camels_730_000
> X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc
> Sender: [email-masked]
> Precedence: bulk
> Reply-To: [email-masked]
> List-Archive: <http://playground.sun.com/mobile-ip/>
> List-Owner: <mailto:[email-masked]>
> List-Subscribe: <mailto:[email-masked]?body=subscribe>
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> Status: RO
> X-Status: $$$$
> X-UID: 0000000001
>
> --Caravan_of_Camels_730_000
> Content-Type: TEXT/plain; charset=us-ascii
> Content-MD5: G3uHCN4s1dqOpvzUeHXptA==
>
> Hi Charlie,
>
> As you remember, I had given a presentation on the Mobile IP spec discussion we
> had at Connectathon 2001 at IETF50. And after the IETF meeting, I had sent the
> attached e-mail to this alias. Both presentation and the e-mail list the Mobile
> IPv6 spec issues we identifed during the Connectathon discussions.
>
> Looking at the version 14 of the draft, I'm not able to see if any of this
> feedback made into the spec. Was there some technical reasons these are not
> incorporated into the draft?
>
> Thanks Charlie,
>
> alper
>
> > X-Unix-From: [email-masked]  Sun Jul  1 00:08:37 2001
> > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to
> [email-masked] using -f
> > X-Delivered-For: <[email-masked]>
> > X-mProtect: Sun, 1 Jul 2001 00:06:10 -0700 Nokia Silicon Valley Messaging
> Protection
> > X-Accept-Language: en
> > MIME-Version: 1.0
> > To: Mobile IP Working Group <[email-masked]>
> > Subject: [mobile-ip] draft-ietf-mobileip-ipv6-14.txt
> > Content-Transfer-Encoding: 7bit
> > List-Archive: <http://playground.sun.com/mobile-ip/>
> > List-Owner: <mailto:[email-masked]>
> > List-Subscribe: <mailto:[email-masked]?body=subscribe>
> > List-Unsubscribe:
> <mailto:[email-masked]?body=unsubscribe>
> >
> > Hello folks,
> >
> > I believe that most of the current issues with Mobile IPv6 are
> > resolved at least to the point of some local equilibrium --
> > except, of course, that we still do not know how to evaluate
> > security design decisions.  Thus, I have supplied a newly
> > revised text to be distributed.  It is also available at the
> > following URL:
> >       http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt
> >
> > The new text is improved (thanks to Ken and T.J. and Mattias)
> > from the drafty version publicized a couple of weeks ago.
> > No major comments about the reduced reliance on AH were received,
> > and so I thought that the newly specified structure for the
> > Binding Update option was acceptable.  If not, I'll happily
> > make whatever changes are required, including going back to
> > a design which relies on AH.
> >
> > There is one unsatisfied citation -- namely, the citation for
> > the as yet unidentifiable key distribution draft.  The Mobile IPv6
> > draft is completely neutral on this subject; there is only the
> > (currently false) assumption that some key distribution draft
> > does exist.
> >
> > Other changes include the new Mobile Prefix Advertisement
> > message for distributing prefix information to roaming mobile
> > nodes whenever necessary, and a scheduling algorithm for that.
> > Please consult the "Changes" section of the appendix for a more
> > complete list.
> >
> > Comments are welcome as always; please send editorial comments to
> > me directly, and design questions, improvements, and observations
> > to the list.
> >
> > Regards,
> > Charlie P.
>
> alper
>
> --Caravan_of_Camels_730_000
> Content-Type: MESSAGE/rfc822; name=Mailbox
> Content-Description: Mailbox
>
> X-Unix-From: [email-masked]  Fri Apr  6 18:21:46 2001
> Return-Path: <[email-masked]>
> Received: from engmail3.Eng.Sun.COM (engmail3.Eng.Sun.COM [129.144.170.5])
>         by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371LiCp179357;
>         Fri, 6 Apr 2001 18:21:44 -0700 (PDT)
> Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
>         by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13906;
>         Fri, 6 Apr 2001 18:21:35 -0700 (PDT)
> Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
>         by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371FBK9002255
>         for <[email-masked]>; Fri, 6 Apr 2001 18:15:11 -0700 (PDT)
> Received: (from majordomo@localhost)
>         by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f371FBFo002254
>         for mobile-ip-dist; Fri, 6 Apr 2001 18:15:11 -0700 (PDT)
> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to [email-masked] using -f
> Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged))
>         by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371F2K9002247
>         for <[email-masked]>; Fri, 6 Apr 2001 18:15:02 -0700 (PDT)
> Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247])
>         by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f371F1Cq178579;
>         Fri, 6 Apr 2001 18:15:02 -0700 (PDT)
> Message-Id: <[email-masked]>
> Date: Fri, 6 Apr 2001 18:12:30 -0700 (PDT)
> From: Alper Yegin <[email-masked]>
> Subject: [mobile-ip] Mobile IPv6 spec issues from Connectathon 2001
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> MIME-Version: 1.0
> Content-Type: TEXT/plain; charset=us-ascii
> Content-MD5: sq6axuflJNFK1ou9PzqaKQ==
> X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc
> Sender: [email-masked]
> Precedence: bulk
> Reply-To: [email-masked]
> List-Archive: <http://playground.sun.com/mobile-ip/>
> List-Owner: <mailto:[email-masked]>
> List-Subscribe: <mailto:[email-masked]?body=subscribe>
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> Content-Length: 4253
> Status: RO
>
> This message didn't show up on the mailing list. Resending...
>
> ------------- Begin Forwarded Message -------------
>
> For the second year Connectathon covered testing both Mobile IPv4 and Mobile
> IPv6 protocols. During the event, Mobile IP participants got together to discuss
> specification related issues. We came up with a number of them, which was
> outlined in the Connectathon presentation given by Carl Williams and myself at
> IETF 50.
>
> Here's a recapture of Mobile IPv6 spec issues, for those who weren't at the IETF
> meeting (in case they have comments), and for the Mobile IPv6 draft authors to
> incorporate these into the next revision of the draft.
>
> Cheers,
>
> Alper Yegin
>
> [1] Movement detection (section 10.4)
>
>    ... Instead,
>    a mobile node SHOULD consider receipt of any IPv6 packets from its
>    current default router as an indication that it is still reachable
>    from the router.  Both packets from the router's IP address and
>    (IPv6) packets from its link-layer address (e.g., those forwarded but
>    not originated by the router) SHOULD be considered.
>
> Draft suggests that receiving packets from a node with same link-layer address
> and IP address as current default router means that mobile node is still
> attached to the same link.
>
> BUT, different interfaces of the same router can have the same MAC address,
> therefore same link-local address but advertise different prefixes. In this
> case, mobile node would fail to detect movement if it only looks at the source
> MAC and IP address of packets.
>
> Therefore draft should not suggest a match on source MAC address and IP address
> is sufficient.
>
> [2] Sending binding acknowledgement for failed binding updates (section 5.2)
>
>    Rather, the care-of address used by this node in
>    sending the packet containing the Binding Acknowledgement MUST be
>    copied from the care-of address received in the rejected Binding
>    Update; ...
>
> Draft says receiving node MUST send a binding acknowledgement for failed binding
> updates. It also says the care-of address MUST be copied from the failed binding
> update.
>
> BUT in the case care-of address is an invalid address such as multicast or
> unspecified address, such an address should not be used as the care-of address
> in binding acknowledgement.
>
> Draft can be updated to say:
> - If we have received this binding update as a home agent, we MUST not send a
> binding acknowledgement
> - If we have received this binding update as a correspondent node, we MUST send
> the binding acknowledgement to home address (or not send at all?)
>
> [3] Home agent address discovery request message (section 5.6)
>
> Home Agent Address Discovery Request Message includes the Home Address field.
> This information is used by the receiving home agent to return the list of home
> agents matching the prefix of the mobile node.
>
> This request packet is sent to "Mobile IPv6 Home-Agents" anycast address for its
> own home subnet prefix.
>
> The receiving home agent can figure out the prefix of the mobile node just by
> looking at the destination address of the request packet. Therefore Home Address
> field in the request message is not needed in the draft.
>
> [4] ICMPs can delete binding cache (section 8.8)
>
>    If the correspondent node
>    receives persistent ICMP Destination Unreachable messages after
>    sending packets to a mobile node based on an entry in its Binding
>    Cache, the correspondent node SHOULD delete this Binding Cache
>    entry.
>
> The only way binding cache entries can be deleted is through binding updates and
> persistent ICMP unreachables. The former is required to be authenticated, but
> not the latter. The draft should have a proper warning about this, as
> unauthenticated ICMP messages can be used for DoS attacks.
>
> [5] Deregistering a care-of address (section 8.5)
>
> The draft says that binding acknowledgement MUST be sent using a routing header
> in the same way as any other packet sent to a mobile node using a care-of
> address.
>
> BUT, what should be the care-of address used in the case this was a
> deregistration? Draft should specify that it MUST be the care-of address used in
> the triggering binding update. (similarly, draft already specifies that for
> failed binding updates case).
>
> ------------- End Forwarded Message -------------
>
> --Caravan_of_Camels_730_000--