Re: (ngtrans) Next steps

["Shiao-Li Tsao (Charles)" <[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>.

Charles> Well, you can say that if you like. :)

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.

Charles> OK, if you put FA in and assume packets should go through FA which
is not dual stack, yes you need some new mechanisms. By the way, the more
limitation and assumption you put in, the smaller problem space your
solution addresses. Maybe your solution is useful, but very limited usage, I
think.

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.

Charles > MIPv4 Reg. provides authentication to MIPv4 HA but does not
provide authentication to 6over4 border router in your case. You assume 6to4
router and MIPv4 HA are co-located but you can not assume that 6over4 router
can get authentication from MN. You are trying to protect HA attack or
6over4 router attack ? That is different.

Charles









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