RE: (ngtrans) Next steps

[Marc Blanchet <[e-mail]>]

-- lundi, mars 25, 2002 10:06:06 -0800 Tony Hain <[e-mail]> 
wrote/a écrit:

> While this discussion on mobility issues has been interesting, the
> continuing use of the term 'assumption' highlights the point of the
> exercise we should be focused on at the moment. For the time being, we
> need to describe the common environments and agree, so personal
> assumptions do not continue to confuse the discussion. There may be a
> case for mobile nodes becoming isolated in areas of the other protocol,

Thinking about MobileIP is one solution to the issue of mobility. However, 
the point of mobile nodes and mobile networks should be taken into account 
as environments/scenarios for transition tools.

I would like to suggest the following environment/scenario to be covered:
- an environment where an dual-stack node (or an IPv6 network attached to a 
dual-stack router) is moving (from the perspective of the IPv4 address 
change (IPv6 could/could not change).

> and if there is we will need someone to lead an effort to describe it

I can do it.

Marc.

>. I
> am not opposed to an open discussion on the list, but please change the
> subject to reflect the discussion topic.
>
> Tony
>
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]On Behalf Of Shiao-Li Tsao
>> (Charles)
>> Sent: Monday, March 25, 2002 2:41 AM
>> To: changwen
>> Cc: Pekka Savola; [e-mail]
>> 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.
>>
>> 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
>> > >
>> >
>>
>



------------------------------------------
Marc Blanchet
Viagénie
tel: [phone]x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------