Re: (ngtrans) Next steps

[changwen <[e-mail]>]

Basically the assumption of MIPv6 HA having IPv4 address differentiates mine from yours. Your draft <MOVING> has that assumption while my draft doesn't. My draft doesn't assume MIPv6 HA having any IPv4 addresses. Only MNv6 has nominal IPv4 home address used for routing IPv6 packets only. So I think I can still stand by my claim that the scenario covered in my draft is not covered in the draft <MOVING>.

For the question on why MIPv4 is involved, the answer in short is packet routing requirement and security benefit provided by MIPv4. 
1. Imagine the scenario that MNv6 gets a FA care-of address (IPv4 address, of course) in the visited IPv4 domain. This will be a typical case for mobility support in IPv4 domain if one thinks of current IPv4 address depletion issue (the major driving force for IPv6 deployment). The FA acts as the first router for MNv6 and routes all the packets to/from MNv6. Obviously one cannot assume the FA understands IPv6. In other words, the FA may not be able to deliver any IPv6 packets for MNv6. So encapsulating IPv6 packets with MNv6's care-of address won't work in this scenario. 
2. The MIPv4 registration provides the authentication to the 6to4 border router for MNv6's v4 binding and hence the 6to4 border router can securely 'redirect' received packets to/from MNv4. The redirect attack from malicious nodes won't work.

Let's me know if I miss any of your points or questions.

Thanks.

changwen 
 
----- Original Message ----- 
  From: Shiao-Li Tsao (Charles) 
  To: changwen 
  Cc: Pekka Savola ; [e-mail] ; Shiao-Li Tsao (Charles) 
  Sent: Sunday, March 24, 2002 6:55 PM
  Subject: Re: (ngtrans) Next steps


  The scenario is covered by <MOVING>. The situation you mentioned is basically a dual stack mobile node using IPv6 (DS MNv6) moves to IPv4-only network. I agree this scenario is useful. I think the only difference is that you apply different assumption on HA which has no IPv4 address (or has no permanent IPv4 address). However, I don't think MIPv4 should be involved in your situation. If MN has a pre-configured 6to4 border router and it can obtain a CoA in the visited network (these are your assumptions), why not to send a MIPv6 BU destinated to HA (encapsulated in IPv4) to a border router ? The border router can be seen as a tunneling end point, decapsulates IPv4 packets and forwards MIPv6 BU to HA. Please correct me if anything I miss. 

  Charles

    ----- Original Message ----- 
    From: changwen 
    To: Shiao-Li Tsao (Charles) 
    Cc: [e-mail] ; 'Tony Hain' ; Margaret Wasserman ; Alain Durand ; Bob Fink ; Randy Bush ; Pekka Savola 
    Sent: Tuesday, January 14, 2003 9:56 AM
    Subject: Re: (ngtrans) Next steps


    > Personally, I think mobility in transition network should be investigated.
    > However, the preliminary study <MOVING> shows that most of the mobility in
    > v4v6 transition is either trivial or the solutions are straightforward.
    > Maybe some other situations need to be discussed if we can show the specific
    > scenarios are pratical or they attract global interestings.

    Well, one important scenario that is not covered by <MOVING>  is the case that dual stack capable MNv6 whose MIPv6  home agent has no IPv4 address roams into IPv4 domain. 

    A common belief is that IPv6 will be first deployed in the edge network site by site (e.g. enterprises) while the core network/Internet still runs IPv4. So it will be common to see a lot of isolated IPv6 only sites connected by IPv4 infrastructure. Needless to say that the 6to4 protocol is a good candidate to run these IPv6 only sites. Two critical facts are that usually only the border routers at these sites have IPv4 addresses due to IPv4 address space depletion and many of these sites will be more than just one single IPv6 subnet, e.g. An enterprise IPv6 site may only have one IPv4 address in its border router and have however multple IPv6 subnets. In other words, it is common that the home agents of MNv6s in these sites have no IPv4 addresses. As time goes by, these sites may also get native IPv6 connections in addition to the IPv4 connections and hence the sites may have both native IPv6 prefixes as well as 6to4 prefixes. However no new IPv4 addresses to the site and the home agents of MNv6s in these sites remain to have no IPv4 addresses. A real issue is then the MNv6s from these sites will very likely roam into IPv4 only domains and keep moving in the IPv4 domains. 

    > Otherwise, I don't see any new ngtrans tool needs be introduced at the
    > current stage.
    > 
    > Charles Tsao

    I believe the above described scenario should attract global interestings and a tool is needed for resolving this issue. 

    changwen

    > 
    > 
    > 
    > ----- Original Message -----
    > From: "Pekka Savola" <[e-mail]>
    > To: "Liu, Changwen" <[e-mail]>
    > Cc: "'Tony Hain'" <[e-mail]>; <[e-mail]>; "Margaret
    > Wasserman" <[e-mail]>; "Alain Durand" <[e-mail]>; "Bob
    > Fink" <[e-mail]>; "Randy Bush" <[e-mail]>
    > Sent: Saturday, March 23, 2002 8:39 PM
    > Subject: RE: (ngtrans) Next steps
    > 
    > 
    > > On Fri, 22 Mar 2002, Liu, Changwen wrote:
    > >
    > > > Tony,
    > > > I believe Mobility should also be one important item in the "Areas
    > > > to cover". In the listed environments, you may have scenarios of v6
    > nodes
    > > > roaming into v6 domain and v4 nodes roaming into v4 domain. Mobility
    > will be
    > > > more than just mixed mode operation and should be addressed separately.
    > >
    > > I disagree.
    > >
    > > Mobility will be more or less trivial in IPv6 operation, and without it
    > > it's just a very rare special case.
    > >
    > > So it's either usually trivial or irrelevant from the global perspective.
    > >
    > > > -----Original Message-----
    > > > From: Tony Hain [mailto:[e-mail]]
    > > > Sent: Friday, March 22, 2002 3:54 PM
    > > > To: [e-mail]
    > > > Cc: Margaret Wasserman; Alain Durand; Bob Fink; Randy Bush
    > > > Subject: (ngtrans) Next steps
    > > >
    > > >
    > > > The discussion in the wg meeting on Monday focused on the charter
    > > > update, and the need to clearly identify viable operational environments
    > > > at different phases of the transition to IPv6. To accomplish that the wg
    > > > will need to establish concise descriptions of each target environment,
    > > > then show how at least one set of tools can be applied to accomplish a
    > > > transition. In addition, if there are specific combinations of tools
    > > > which create security or other problems for a given environment, the wg
    > > > will need to highlight those issues.
    > > >
    > > > To get this effort started and provide a discussion framework, the
    > > > co-chairs developed the following bullet points.
    > > >
    > > > Vision of deployment and related issues in a small set of defined
    > > > environments.
    > > > Goals:
    > > >   provide network managers with at least one viable framework and
    > > > complete tool set for deploying IPv6.
    > > >   expose any mismatch between the requirements of a target environment
    > > > and the ngtrans tool set.
    > > >
    > > > These goals should be self explanatory, but in case there is confusion,
    > > > we are not looking for all possible environments, or approaches to
    > > > deploy IPv6 in an environment. Since we will be describing common
    > > > generic cases, the approach chosen may not even necessarily the best
    > > > approach for any particular network. Rather the goal is to identify
    > > > consistent characteristics of the most common environments.
    > > >
    > > >
    > > > Environments:
    > > >    Unmanaged Network (SOHO lan)
    > > >    Managed Network (Enterprise lan & vpn)
    > > >    ISP service models
    > > >       Dial   :   HFC   :   DSL   :   FtoH   :   3G
    > > >    Services
    > > >       www, smtp, IM, ...
    > > >
    > > > This is not intended to be an exhaustive list, rather an example of ways
    > > > to break down the 'network environment' into manageable size pieces. If
    > > > there are additional environments with wide applicability please raise
    > > > them to the list.
    > > >
    > > > These documents need to describe existing operational environments with
    > > > their unique characteristics, independent of the IPv6 transition
    > > > approaches that might be applied. To the extent that major sections of
    > > > the descriptions are common, the result should be a single document,
    > > > while those cases where some parts are common, but the architectural
    > > > approaches vary widely, there should be multiple documents.
    > > >
    > > > For example, deploying IPv6 in an HFC environment will probably be a
    > > > single document, even though some cable modems act as a bridge while
    > > > others act as routers. Outside of this difference, most of the
    > > > associated infrastructure is common across the majority of service
    > > > providers globally. On the other hand, we expect a 3G cell environment
    > > > will probably be described separately from a Dial environment. While
    > > > they may share a common authentication system, it is likely they have
    > > > little else in common.
    > > >
    > > >
    > > > Areas to cover:
    > > >    How to get started
    > > >    Mixed mode operation
    > > >    Viability & path of removing IPv4
    > > >    Manageability
    > > >    Security concerns
    > > >    Applications and their infrastructure
    > > >    Broad common issues may be in separate docs
    > > >    ISP architecture issues include
    > > >       aaa, prefix allocation, dns registration, tunnel services, .
    > > >
    > > > Once the environment is well described, independent of transition
    > > > technologies, there will need to be one or more documents describing the
    > > > possible application of a set of transition tools, and any issues that
    > > > arise over time. In particular the periods of initial IPv6 use, a 50%
    > > > mixed mode, and phasing out of IPv4 will need to be explicitly
    > > > addressed. If there are other notable combinations for any given
    > > > environment, those are expected to be highlighted as well. In addition
    > > > to the basic description of how a set of tools might be used, there will
    > > > need to be a discussion of manageability, security issues, application
    > > > impact, and any services expectations at each of the phases.
    > > >
    > > >
    > > >
    > > > Until those documents are available, the IESG has no context to evaluate
    > > > the tools against. For this reason, there will be a hold placed on all
    > > > other ngtrans projects at least until IETF-54 in Yokohama. This means
    > > > that there will be no existing project work forwarded to the IESG, and
    > > > no new projects accepted. This does not mean that authors and wg
    > > > participants should stop work on these work items, rather that they will
    > > > be reviewed for appropriateness within the updated ngtrans charter.
    > > >
    > > > The current proposed charter is:
    > > >
    > > > The goals of the NGtrans working group is:
    > > > Document operational requirements and recommended practices for major
    > > > pieces of the Internet infrastructure in a mixed world of IPv4 only,
    > > > IPv6 only and dual stack nodes.  Those pieces include, but are not
    > > > limited to:  Routing, DNS, Mail, Network monitoring, Web, Multicast,
    > > > VoIP,...  This work is to be done in cooperation with the relevant
    > > > experts and/or the relevant working groups when applicable.
    > > >
    > > > Any further work items to be evaluated between now and July
    > > >
    > > > Please send comments about this charter to the list.
    > > >
    > > >
    > > > To get the necessary documents started, we first need to agree on the
    > > > breakdown of the environments. Please keep in mind we are looking for
    > > > the high-level environment, so with or without IPv4 nat should be a
    > > > subset of each environment. Send comments to the list, and we will last
    > > > call the set when it appears the discussion is converging.
    > > >
    > > > After the breakdown is agreed upon, we will be looking for volunteers to
    > > > take the lead on specific documents. The target is to have some
    > > > draft-*-00 versions available for comment before the July submission
    > > > cut-off. After the WG agrees that the document adaquately describes a
    > > > generic target environment, work will begin on the description of how a
    > > > set of the ngtrans tools might apply.
    > > >
    > > >
    > > > The NGtrans co-chairs
    > > > Alain, Margaret, & Tony
    > > >
    > > >
    > >
    > > --
    > > Pekka Savola                 "Tell me of difficulties surmounted,
    > > Netcore Oy                   not those you stumble over and fall"
    > > Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
    > >
    >