Re: Was RE: (ngtrans) Next steps

[changwen <[e-mail]>]

Was RE: (ngtrans) Next steps----- Original Message -----
From: Moter Du
To: 'changwen'
Cc: [e-mail]
Sent: Monday, March 25, 2002 9:06 PM
Subject: Was RE: (ngtrans) Next steps


When a dual-stack-capable-MNv6-whose-MIPv6-home-agent-has-no-IPv4-address
moves into IPv4 domain and starts updating its binding, the mechanism it
delivers the binding update are exactly one of NGTRANS tools which make a
dual-stack node retains IPv6 connections within IPv4 domain.  The draft

====> If there is such a mysterious mechanism, show to this WG IN DETAIL how
it works for IPv6 packets to/from this MNv6.

<MOVING> implies internal implementation of such mobile node has proper
intelligence to handle various scenarios.  It is an implementation issue.
With comprehensive analysis of the draft <MOVING> it can hardly miss any
scenarios.  The one you're to differentiate with does not make a new case.

====> You need to back your assertions with convincing proof  and analysis
for which I haven't seen yet.

Moter

====> changwen

-----Original Message-----
From: changwen [mailto:[e-mail]]
Sent: Wednesday, January 15, 2003 12:02 PM
To: Shiao-Li Tsao (Charles)
Cc: Pekka Savola; [e-mail]
Subject: Re: (ngtrans) Next steps


----- Original Message -----
From: "Shiao-Li Tsao (Charles)" <[e-mail]>
To: "changwen" <[e-mail]>
Cc: "Pekka Savola" <[e-mail]>; <[e-mail]>
Sent: Monday, March 25, 2002 2:41 AM
Subject: Re: (ngtrans) Next steps


> 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.
>
A little bit more clarification and differentiation between my draft
(referred as <mipv6overmipv4> hereafter) and the draft <MOVING> are
justified.
1. MNv6 in draft <mipv6overmipv4> works with both co-located CoA and FA-loca
ted CoA cases in visited IPv4 domain. In other words, if MNv6 gets
co-located CoA from FA or  DHCP server or through any other mechanisms, IPv6
packets from/to this MNv6 can be correctly routed. If MNv6 can only gets
FA-located CoA from FA, IPv6 packets from/to this MNv6 can still be
correctly routed. FA is not requirement in draft <mipv6overmipv4> and
however is supported. I am not requiring FA in the packet routing path.
Since FA-located CoA puts much less pressure on already very tight IPv4
address space, it is more likely to be a real deployment scenario in visited
IPv4 domain (where FA is deployed). So support for FA-located CoA is a plus,
not a minus.
2. MNv6 in draft <MOVING> works only with co-located CoA in visited IPv4
domain. In particular I believe it breaks with FA-located CoA. In other
words, if MNv6 gets co-located CoA from FA or  DHCP server or through any
other mechanisms, IPv6 packets from/to this MNv6 can be correctly routed.
However if MNv6 can only gets FA-located CoA from FA (that is not dual stack
capable), I don't see how IPv6 packets from/to this MNv6 can be correctly
routed. It seems to me that the co-located CoA for MNv6 is a requirement in
draft <MOVING>.
So it is clear which draft has more limitations and which has fewer
limitations and hence more usage.


> 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
Thanks for the clarification. The draft <mipv6overmipv4> assumes MIPv4 HA is
co-located with the 6to4 border router. The authentication protects redirect
attacks against HA as well as all MNv6s supported by the HA/border router.
changwen
>
>
>
>
>
>
>
>
>
> 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
> > >
> >
>