Re: [MEXT] Issue #11: De-registration when returning home

Hi Vijay, 

this is fine to me

Thanks
Gerardo

________________________________________
From: mext-bounces <at> ietf.org [mext-bounces <at> ietf.org] On Behalf Of Vijay Devarapalli [vijay <at> wichorus.com]
Sent: Friday, October 31, 2008 3:56 PM
To: Charles E. Perkins; mext <at> ietf.org
Subject: Re: [MEXT] Issue #11: De-registration when returning home

Hi Charlie,

In the previous discussions on this issue (July 2008), we had almost
concluded on the following text.

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), when the
   mobile node detects that its home subnet prefix is again on-link.
   To be able to send and receive packets using its home address from
   the home link, the mobile node MUST send a Binding Update to its
   home agent to instruct its home agent to no longer intercept or
   tunnel packets for it. Until the mobile node sends a de-registration
   Binding Update, it will not be able to send and receive packets
   using its home address from the home link. The home agent will
   continue to intercept all packets sent to the mobile's home address
   and tunnel to the previously registered care-of address.

Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing loop between home agents

Hi Vijay, Charlie and all,

I tend to agree with Raj that this does not seem a MIP6-specific issue or at least it does not require any
MIP6-specific solution.

While the way of creating the routing loop is specific to MIP6, in the sense that MIP6 signaling is used, the
outcome of the attack may be just a flood of packets to the HA. How is this flooding of packets different from
any other DoS/flooding? Does the HA anyway be equipped to drop packets in case of packets floods?

The HA may just drop packets if they exceed a ceratin threshold and optionally delete the binding. This
seems to be enough in my view considering that there is anyway a long trust relationship between the
attacker (i.e. the MN) and the HA.

What do you think?

Gerardo

________________________________________
From: mext-bounces <at> ietf.org [mext-bounces <at> ietf.org] On Behalf Of Vijay Devarapalli [vijay <at> wichorus.com]
Sent: Friday, October 31, 2008 4:15 PM
To: Charles E. Perkins; Benjamin Lim
Cc: mext <at> ietf.org
Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing        loop between home agents

Hi Charlie,

> -----Original Message-----
> From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On
> Behalf Of Charles E. Perkins
> Sent: Thursday, October 02, 2008 4:51 PM

[MEXT] Draft agenda for ietf 73

Hi,

Please find a first version of the agenda at:

http://www3.ietf.org/proceedings/08nov/agenda/mext.txt

Let me know if something is missing or should be changed.

Regards, marcelo

[MEXT] I-D Action:draft-ietf-mip6-radius-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : RADIUS Mobile IPv6 Support
	Author(s)       : A. Lior, et al.
	Filename        : draft-ietf-mip6-radius-06.txt
	Pages           : 48
	Date            : 2008-11-03

This document defines new attributes to facilitate Mobile IPv6
operations using RADIUS infrastructure.  The operations include
bootstrapping of information required by the Mobile Node and the
interface between the Network Access Server, Home Agent and the
RADIUS server used to assist MIP6 operations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
MEXT mailing list
MEXT <at> ietf.org

[MEXT] A few findings on the binding revocation draft

Hi all,

here are some newcomer's findings on the
binding revocation draft -01:

1) In Fig 2 and 3 there is a field "Cause" in BRA.
    Where is it defined in more detail?

2) In 9.1.1. it is stated that "The Global (G) bit MUST
    be set and..." without any conditions. However, in the
    next bullet, it is stated that "Whenever the Global (G)
    bit is set", implying that it does not always need to
    be set. These texts are controversial and should be fixed.

Some typos found:

3.4.3: "LMA may only supports IPv4" -> "LMA may only support IPv4"

8.2: "the home SHOULD examine" -> "the home agent SHOULD examine"

      "the home agent delete" -> "the home agent deletes"

9.1.1: "anchor send a" -> "anchor sends a"

        "LMA MUST sends a" -> "LMA MUST send a"

Best regards,
Teemu Rinta-aho

--

Re: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP

Vijay,

> >>> Wouldn't a new DSMIP companion document just define a new
> >>> mobility option to use with HA Switch and how it should be used? 
> >>> I wouldn't think we'd revise 5142 to add DSMIP-specific content
> >>> to it.
> >>
> >> That will result in two documents for the same purpose. We should
> >> avoid that. I don't see any issue with 5142bis talking about the
> >> IPv4 home agent address.
> >
> > I see a possible issue with having both plain-MIPv6 and DSMIPv6
> > support in the same RFC, e.g. 5142bis.
> >
> > There will be MIPv6 only systems with HA switch functionality but
> > without DSMIP capability. Can such systems claim conformance to
> > 5142bis?
>
> We can add a mobility option for the carrying the HA IPv4 address,
> not modify the message itself. Existing implementations would become
> conformant to 5142bis when they get updated to support the new
> mobility option. This is normal, though.

But I don't see why a MIPv6 only systems would need to support the new 
(IPv4) option when it doesn't support DSMIPv6...

I think we should define the new option in a new document.

--julien

[MEXT] FW: New Version Notification for draft-ietf-mext-nemo-v4traversal-06

FYI

------ Forwarded Message
> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: Mon,  3 Nov 2008 07:19:19 -0800 (PST)
> To: Hesham Soliman <hesham <at> elevatemobile.com>
> Cc: Hesham Soliman <hesham <at> elevatemobile.com>
> Subject: New Version Notification for draft-ietf-mext-nemo-v4traversal-06
> 
> 
> A new version of I-D, draft-ietf-mext-nemo-v4traversal-06.txt has been
> successfuly submitted by Hesham Soliman and posted to the IETF repository.
> 
> Filename:  draft-ietf-mext-nemo-v4traversal
> Revision:  06
> Title:   Mobile IPv6 Support for Dual Stack Hosts and Routers
> Creation_date:  2008-11-03
> WG ID:   mext
> Number_of_pages: 50
> 
> Abstract:
> The current Mobile IPv6 and NEMO specifications support IPv6 only.
> This specification extends those standards to allow the registration
> of IPv4 addresses and prefixes, respectively, and the transport of
> both IPv4 and IPv6 packets over the tunnel to the home agent.  This
> specification also allows the Mobile Node to roam over both IPv6 and
> IPv4, including the case where Network Address Translation is present
> on the path between the mobile node and its home agent.
>                  
> 

Re: [MEXT] I-D Action:draft-ietf-mip6-radius-06.txt

Hi folks

Please check if the draft supports dual stack MIPv6.

The corresponding Dimameter draft can be referred to
http://tools.ietf.org/id/draft-ietf-dime-mip6-split-13.txt.

BR
Frank

----- Original Message ----- 
From: <Internet-Drafts <at> ietf.org>
To: <i-d-announce <at> ietf.org>
Cc: <mext <at> ietf.org>
Sent: Monday, November 03, 2008 2:45 AM
Subject: [MEXT] I-D Action:draft-ietf-mip6-radius-06.txt

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
> This draft is a work item of the Mobility EXTensions for IPv6 Working 
> Group of the IETF.
>
>
> Title           : RADIUS Mobile IPv6 Support
> Author(s)       : A. Lior, et al.
> Filename        : draft-ietf-mip6-radius-06.txt
> Pages           : 48
> Date            : 2008-11-03
>
> This document defines new attributes to facilitate Mobile IPv6

[MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Mobile IPv6 Support for Dual Stack Hosts and Routers
	Author(s)       : H. Soliman
	Filename        : draft-ietf-mext-nemo-v4traversal-06.txt
	Pages           : 50
	Date            : 2008-11-03

The current Mobile IPv6 and NEMO specifications support IPv6 only.
This specification extends those standards to allow the registration
of IPv4 addresses and prefixes, respectively, and the transport of
both IPv4 and IPv6 packets over the tunnel to the home agent.  This
specification also allows the Mobile Node to roam over both IPv6 and
IPv4, including the case where Network Address Translation is present
on the path between the mobile node and its home agent.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________

Re: [MEXT] A few findings on the binding revocation draft

Hi Teemu,

Thanks for the comments. Please see inline.

Regards,
Ahmad

> -----Original Message-----
> From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On 
> Behalf Of Teemu Rinta-aho
> Sent: Monday, November 03, 2008 4:27 AM
> To: mext <at> ietf.org
> Subject: [MEXT] A few findings on the binding revocation draft
> 
> Hi all,
> 
> here are some newcomer's findings on the binding revocation draft -01:
> 
> 1) In Fig 2 and 3 there is a field "Cause" in BRA.
>     Where is it defined in more detail?

[Ahmad]
Thanks. This needs to be corrected and replaced by "Status"

> 
> 2) In 9.1.1. it is stated that "The Global (G) bit MUST
>     be set and..." without any conditions. However, in the
>     next bullet, it is stated that "Whenever the Global (G)
>     bit is set", implying that it does not always need to
>     be set. These texts are controversial and should be fixed.