Home
Vendor
Project
  Phase I
Press
  Phase I
About
You Are Using IPv4 To Access This Site
Your IP Address is: 38.103.63.55

[moonv6] Re: [nav6tf] ACTION : IETF softwires problem statement

New Message Reply Date view Thread view Subject view Attachment view

From: JORDI PALET MARTINEZ (jordi.palet@consulintel.es)
Date: 11/26/05


moonv6 post from JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Hi Jim, all,

A small clarification. Softwire is a WG already. The IESG announced it the same day we had scheduled the 2nd BoF meeting in Vancouver, so actually it was no longer a BoF but a WG meeting.

They also said should keep softwire instead of softwires, because some ridiculous limitation in the number of letters of the WG names :-(

Regards,
Jordi

> De: "Bound, Jim" <Jim.Bound@hp.com>
> Responder a: <owner-nav6tf@ipv6forum.com>
> Fecha: Sat, 26 Nov 2005 10:31:57 -0500
> Para: <nav6tf@ipv6forum.com>, <moonv6@io.iol.unh.edu>
> CC: "Bound, Jim" <jim.bound@hp.com>
> Conversación: ACTION : IETF softwires problem statement
> Asunto: [nav6tf] ACTION : IETF softwires problem statement
>
> Folks,
>
> There is a new IETF effort and potential working group in the IETF named
> softwires. A description of the work planned is below. In addition the
> latest draft is attached.
>
> I would like to gather input for the chairs relative to and to support
> the problem statements. I do not want this to be a discussion of the
> validity or charter of the working group though so please lets not do
> that, and if you have input on that join the IETF mail list for
> softwires.
>
> Specifically:
>
> First: Can you send mail to me or the list regarding supporting data for
> IPv6 Dominant networks and strategy, that you are seeing in your work.
> Or where you believe Native IPv6 networks are important.
>
> Second: Can you send mail to me or the list on the basic problem
> statement as defined below.
>
> I will collect all responses and send them to the softwires chairs.
>
> Draft Introduction:
>
> The Softwires Working Group is specifying the standardization of
> discovery, control and encapsulation methods for connecting IPv4
> networks across IPv6 networks, IPv6 networks across IPv4 networks in
> a way that will encourage multiple, inter-operable vendor
> implementations.
>
> An important aspect of the problem to keep in mind is that softwires
> are to be used in IP based networks to forward both unicast and
> multicast trafic. They are also assumed to be non-ephemeral in
> nature thus, they are peristent or long-lived. Last, the setup time
> of a softwire is expected to be a very small fraction of the total
> setup time of the CPE/Address Family Boundry Router (AFBR)
>
> At the Paris softwire interim meeting in October, 2005, participants
> divided the overall problem space into two separate "sub-problems" to
> solve based on network topology. These two problems are referred to
> as "Hub and Spoke" (Described in Section 4) and "Mesh" (Described in
> Section 5). The primary difference between these two problems are
> how many connections and associated routes are managed by each IPv4
> or IPv6 island. Hub and Spoke is characterized with one connection
> and associated static default route, and Mesh is characterized by
> multiple connections and routing prefixes. During the solution phase
> of the WG, these problems will be treated as related, but separable,
> problem spaces. Similar protocols and mechanisms will be used when
> necessary, but may vary when necessary to optimize for the
> requirements of the given problem space.
>
> thanks for your support,
>
> /jim
>
>
>
> Network Working Group X. Li
> Internet-Draft CERNET
> Expires: May 18, 2006 A. Durand
> Comcast
> S. Miyakawa
> xxx
> J. Palet
> Consulintel
> F. Parent
> xxx
> D. Ward
> xxx
> November 14, 2005
>
>
> Softwire Problem Statement
> draft-ietf-softwire-problem-statement-00.txt
>
> Status of this Memo
>
> By submitting this Internet-Draft, each author represents that any
> applicable patent or other IPR claims of which he or she is aware
> have been or will be disclosed, and any of which he or she becomes
> aware will be disclosed, in accordance with Section 6 of BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.php.
>
> This Internet-Draft will expire on May 18, 2006.
>
> Copyright Notice
>
> Copyright (C) The Internet Society (2005).
>
> Abstract
>
> This document defines problem statements for the Softwire Working
>
>
>
> Li, et al. Expires May 18, 2006 [Page 1]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> Group to solve. At the highest level, the softwire WG is tasked to
> identify, and extend where necessary, standard protocols to support a
> selected set of IPv4 in IPv6 and IPv6 in IPv4 transition problems.
> This document describes the distinct problems that will be solved as
> part of a solution phase following the completion of this document.
> Some individual requirements (and non-requirements) are also
> identified in this document at times in order to better describe the
> specific scope for a given problem definition.
>
>
> Table of Contents
>
> 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
> 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
> 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
> 3. Hubs and Spokes Problem . . . . . . . . . . . . . . . . . . . 5
> 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5
> 3.2. Network Address Translation (NAT) and Port Address
> Translation (PAT) . . . . . . . . . . . . . . . . . . . . 5
> 3.3. Non upgradable CPE router . . . . . . . . . . . . . . . . 5
> 3.4. Static Prefix Delegation . . . . . . . . . . . . . . . . . 6
> 3.5. Softwire Initiator . . . . . . . . . . . . . . . . . . . . 6
> 3.6. Softwire Concentrators . . . . . . . . . . . . . . . . . . 6
> 3.7. Softwire Concentrator Discovery . . . . . . . . . . . . . 7
> 3.8. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 7
> 3.9. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7
> 3.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
> 3.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7
> 3.12. Operations and Management (OAM) . . . . . . . . . . . . . 7
> 3.13. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8
> 4. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . . . 9
> 4.1. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . 10
> 4.2. Mesh Description . . . . . . . . . . . . . . . . . . . . . 10
> 4.3. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 11
> 4.4. Persistence, Discovery and Setup Time . . . . . . . . . . 11
> 4.5. AF/SAF Reachability . . . . . . . . . . . . . . . . . . . 12
> 4.6. Softwire Encapsulation . . . . . . . . . . . . . . . . . . 12
> 4.7. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
> 4.8. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
 > 4.9. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 13
> 5. Problems: Contrast & Compare . . . . . . . . . . . . . . . . . 14
> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
> 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
> Intellectual Property and Copyright Statements . . . . . . . . . . 18
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 2]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 1. Requirements Notation
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 3]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 2. Introduction
>
> The Softwires Working Group is specifying the standardization of
> discovery, control and encapsulation methods for connecting IPv4
> networks across IPv6 networks, IPv6 networks across IPv4 networks in
> a way that will encourage multiple, inter-operable vendor
> implementations.
>
> An important aspect of the problem to keep in mind is that softwires
> are to be used in IP based networks to forward both unicast and
> multicast trafic. They are also assumed to be non-ephemeral in
> nature thus, they are peristent or long-lived. Last, the setup time
> of a softwire is expected to be a very small fraction of the total
> setup time of the CPE/Address Family Boundry Router (AFBR)
>
> At the Paris softwire interim meeting in October, 2005, participants
> divided the overall problem space into two separate "sub-problems" to
> solve based on network topology. These two problems are referred to
> as "Hub and Spoke" (Described in Section 4) and "Mesh" (Described in
> Section 5). The primary difference between these two problems are
> how many connections and associated routes are managed by each IPv4
> or IPv6 island. Hub and Spoke is characterized with one connection
> and associated static default route, and Mesh is characterized by
> multiple connections and routing prefixes. During the solution phase
> of the WG, these problems will be treated as related, but separable,
> problem spaces. Similar protocols and mechanisms will be used when
> necessary, but may vary when necessary to optimize for the
> requirements of the given problem space.
>
> 2.1. Terminology
>
> Address Family - IPv4 or IPv6
>
> AFBR - Address Family Boundry Router (aka PE)
>
> CPE - Customer Premisis equipment (Host, small router, or "modem")
>
> Softwire (SW) - A "tunnel" that is created on the basis of a control
> protocol setup between softwire endpoints with shared point-to-point
> or multipoint-to-point state. Softwires are generally dynamic in
> nature (they may be brought up and down on demand from any side of
> the softwire), but may be very long-lived.
>
> The node hosting the end of the softwire within the customer network
> is called the softwire initiator.
>
> The node hosting the end of the softwire within the ISP network is
> called the softwire concentrator.
>
>
>
> Li, et al. Expires May 18, 2006 [Page 4]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 3. Hubs and Spokes Problem
>
> The "Hubs and Spokes" problem is named in reference to the airline
> industry where major companies have establised a relatively small
> number of well connected hubs and then deserve smaller airports from
> those hubs.
>
> 3.1. Description
>
> In this problem, ISPs (or large enterprise networks acting as ISP for
> their internal resources) establish a dual stack core (either
> natively or by running tunnels, potentially managed by softwires in a
> "Mesh" problem) and a number of dual stack Points of Presence (POP)
> where they connect their customers. However, one or two things may
> happen:
>
> a) the networks between the CPE router and the POP supports only one
> address family.
>
> b) the CPE router cannot be easily upgraded to support both address
> families.
>
> Equipment cost, operational cost, complexity of running a dual-stack
> network, reluctance to touch CPE, etc. are all reasons brought
> forward when asked why the invervening network cannot be dual-stack
> throughout.
>
> 3.2. Network Address Translation (NAT) and Port Address Translation
> (PAT)
 >
> When connecting IPv6 islands through IPv4 networks, it is assumed
> that one or more IPv4 NAT/PATs MAY exist on the intervening IPv4
> network. At this point in time, neither IPv6 NAT nor IPv6 PAT has
> been defined, so no special consideration will be made for those
> cases.
>
> There is no requirement to be able to "autodetect" NAT or PAT
> presence during softwire setup.
>
> 3.3. Non upgradable CPE router
>
> When the CPE router cannot run in dual stack mode, a softwire will
> have to be established by a node located behind that CPE router.
> This can be accomplished either by a regular PC in the home running
> some ad-hoc software or by a dedicated piece of hardware acting as
> the "IPv6 router". Such a device is fairly simple in design and only
> requires one physical network interface.
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 5]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 3.4. Static Prefix Delegation
>
> An important characteristic of this problem in IPv4 networks is that
> the ISP-facing CPE IP address is typically dynamically assigned.
> Also, if the softwire has to be establish from a node behind a CPE
> router, that node IP address can also be dynamically assigned. In
> cases where static IP addresses are unavailable, dynamic addresses
> are a problem for some Internet accessible services. Solutions like
> external dynamic DNS and dynamic NAT port forwarding have been
> deployed, but it would be simpler if, in IPv6 netwroks, a static
> prefix was delegated to the customer, even in the case of single node
> network. That prefix would allow for the registration of stable
> addresses in the DNS and also enough room to use either RFC3041
> privacy extension or cryptographically generated addresses (CGA).
> The softwire protocol does not need to define a new method for prefix
> delegation however DHCPv6 prefix delegation MUST be able to run over
> a softwire. Note also that the IP addresses of the softwire link
> itself do not need to be stable, as, even in the single PC being
> attached behind it, a /64 prefix will be delegated.
>
> Similarly, in the case of an IPv4 softwire, the address could be
> provided by means of DHCP.
>
> 3.5. Softwire Initiator
>
> In the Hub and Spoke problem, softwires are always initiated by the
> customer side. Thus, the node hosting the end of the softwire within
> the customer network is called the softwire initiator. It can run on
> a simple dual stack host or a local dual stack router. As noticed
> earlier, this can be the CPE access router, another dedicated CPE
> router behind the CPE access router or simply a host.
>
> The softwire initiator does not have to be always the same node
> and/or always have the same IP address. In particular, in the
> nomadic case (e.g. a user opening up his laptop in various wifi hot-
> spots), the softwire initiator could potentially obtain an IP address
> of one address family outside its original ISP network and still want
> to obtain the other address family addresses from its original ISP.
>
> 3.6. Softwire Concentrators
>
> On the ISP side, softwires are termintated on a softwire
> contentrator. An ISP may deploy several concentrators (for example
> one per POP) for scaling reasons. A concentrator is in practice a
> dual stack router connected to the dual stack core ISP
> infrastructure. Softwire concentrators are not nomadic and have
> fixed IP addresses.
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 6]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 3.7. Softwire Concentrator Discovery
>
> When the initiator of the softwire is a CPE, the IP address or DNS
> hostname of the softwire concentrator must be known. The simplest
> way for this to be known by the CPE is for it to be configured by the
> user, or by the provider of the CPE in advance. Alternatively, an
> automated discovery phase may be run in order to return the IP
> address(s), or hostname(s) of the concentrator. The details of this
> discovery problem are outside the scope of this document.
>
> 3.8. Scaling
>
> In a hub and spoke model, an ISP MUST scale the solution to millions
> of softwire inititators by adding more hubs (i.e. softwire
> concentrator).
>
> 3.9. Routing
>
> As customers networks are typically attached via a single link to
> their ISP, a default or static route is the only thing that is needed
> for both address families.
>
> 3.10. Multicast
>
> The "classic" multicast solutions can be used over the softwire.
> Typically, such solution would be either proxy MLD/IGMP and PIM.
>
> NOTE: need to add a reference to "classic" multicast.
>
> 3.11. Security
>
> User Authentication
>
> The softwire must support some method of simple user authentication
> in order to accept or deny access to this service, provide adequate
> logging of activity, etc.
>
> Privacy, Integrity, and Replay protection
>
> The softwire Control and/or Data plane MUST be able to provide full
> payload security (such as IPsec or SSL) when desired. This
> additional protection MUST be separable from the tunneling aspect of
> the softwire mechanism itself. For IPsec, default profiles MUST be
> defined (as per Steve Bellovin documents, insert reference).
>
> 3.12. Operations and Management (OAM)
>
> As it is assume that the softwire may have to go accross NAT or PAT,
>
>
>
> Li, et al. Expires May 18, 2006 [Page 7]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> a keepalive mechanism MUST be define. Such a mechanism is also
> useful for dead peer detection. However it may consume unnecessary
> bandwidth, so turning it on or off MUST be an administrative option.
>
> Other OAM needed features include:
>
> - Usage accounting
>
> - End-point failure detection (must be encapsulated w/in the tunnel
> in the transmitting direction
>
> - Path failure detection)
>
> 3.13. Encapsulations
>
> IPv6/IPv4, IPv6/UDP/IPV4 and IPv4/IPv6 are on the critical path for
> softwires. Other encapsulations, like IPv6/IPv6 or IPv4/IPv4, are
> nice to have but not on the critical path.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 8]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 4. Mesh Problem
>
> Reference Diagram
>
>
> ._._._._ ._._._._
>
> | | | |
>
> | V4 | | V4 |
>
> |access | |access |
>
> |island | |island |
>
> ._._._._ ._._._._
>
> | |
>
> | |
>
> BGP BGP
 >
> Dual-Stack Dual-Stack
>
> "AFBR" "AFBR"
 >
> | |
>
> | |
>
> ._._._._._._._._._._._._._._
>
> | |
>
> | |
>
> ._._._._ | | ._._._.
>
> | | | V6 only | | |
>
> | V6 |-------| transit core |-------| V6 |
>
> |access | | | |access |
>
> |network| | | |network|
>
> ._._._._ | | ._._._.
>
>
>
> Li, et al. Expires May 18, 2006 [Page 9]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> | |
>
> ._._._._._._._._._._._._._._
>
> | / \ |
>
> |/ \ |
>
> BGP BGP
 >
> Dual-Stack Dual-Stack
>
> "AFBR" "AFBR"
 >
> | | |
>
> | | |
>
> ._._._._ ._._._._
>
> | | | |
>
> | V4 | | V4 |
>
> |access | |access |
>
> |island | |island |
>
> ._._._._ ._._._._
>
>
> Figure 1
>
> 4.1. Mesh Problem
>
> The "Mesh" problem in named in reference to typical routing problems.
>
> 4.2. Mesh Description
>
> In this problem, ISPs (or large enterprise networks acting as ISP for
> their internal resources) establish connectivity to 'islands' of
> networks of one address family type across a transit core of a
> differing address family type. For an example, See Figure 1. Note
> that this is just an example and the converse AF problem may exist.
> To provide reachability across the transit core, dual-stack devices
> are installed that act as "Address Family Boundary Routers." These
> AFBRs can be performing peering across autonomous systems or,
> performing as Provider Edge routers (PE) within an autonomous system.
>
>
>
> Li, et al. Expires May 18, 2006 [Page 10]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> The islands do not have to be upgraded at the time of deploying the
> transit core and interwork as if there was no awareness of the AFBR.
>
> The AFBR's are the only devices in the network that must be able to
> perform dual-stack operations and setup and encapsulate softwires in
> a mesh to the other islands. They then pass reachability information
> as appropriate according to policy. They may be multiply connected
> to the transit network and thus, have to be able to exchange
> appropriate informations and make a routing selection choice as to
> the best exit point. Note that this creates a multipoint to point
> reachability but, in essence a point to point logical overlay of
> softwire connectivity.
>
> It should be noted that according to reports the islands do not want
> to achieve network connectivity via tunneled Layer 2 mechanisms but,
> as distinct Layer 3 or MPLS routers. This clearly helps scaling and
> Layer 2 discovery performance issues. It also prevents having to
> have fully meshed point to point Layer 2 connectivity between the
> nodes in differing islands as Layer 2 technology choice must be
> preserved.
>
> 4.3. Scaling
>
> In the mesh problem, the number of AFBRs is on the order of the
> number of islands though it should be clear that an AFBR could handle
> many islands if they have distinct routing and forwarding tables. A
> primary issue in the Mesh problem is that the size of the routing
> tables exchanged between the islands is of the order of the 'full
> Internet' (with respect to the islands native AF) plus, VPNs. The
> number of peering points of an AFBR will be on the order of any
> Autonomous System Border Router (ASBR) which are assumed to be
> multiply peered to the transit core for reliability. An island can
> also have multiple AFBRs for reliability as well. Both the island or
> the transit core can contain route reflectors or hierarchical routing
> with impunity.
>
> 4.4. Persistence, Discovery and Setup Time
>
> Discovery of the AFBRs and softwire encapsulation can be accomplished
> by the routing protocol (e.g. BGP) during capability advertisement.
> Or, the endpoints can be passed in new data formats or attributes,
> yet to be defined. The duration of the softwire for inter-island
> reachability is considered to be as long as the BGP peering session.
> Thus, dynamicity is very low. The setup time should be on the order
> of the same duration to setup L3VPNs.
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 11]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 4.5. AF/SAF Reachability
>
> It has been reported that the softwires to connect the islands will
> need to be able to perform IPv4 in IPv6, IPv6 in IPv4 and be able to
> exchange L3VPN routing tables. The islands will need to be able to
> perform multicast routing and if the transit core does not provide
> native multicast services, the "classic" multicast solutions can be
> used over the softwire. If native multicast services are enabled,
> further work may need to be accomplished to optimize the multicast
> forwarding path, receiver transmission load or receiver load.
>
> 4.6. Softwire Encapsulation
>
> In the strictest sense, the softwire encapsulation has to be dual
> stack. There is no requirement that only one encapsulation technique
> must be used. It could be possible to have more than one available
> at each AFBR. The AFBR must be able to prioritize which
> encapsulation technique it will use if there is more than one
> available.
>
> 4.7. Security
>
> In contrast with the hub and spoke problem, routers are advertizing
> routers for relatively large islands, and never a single user so
> there is no "user authentication" necessary. However, if running
> over an untrusted network, control or data plane security may be
> necessary.
>
> In the control plane, the softwire solution has to support
> authentication, but an ISP may decide to turn it off in some
> circumstances.
>
> In the data plane, the softwire solution must support IPsec and an
> IPsec profile will have to be defined. (see Steve Bellovin
> recomendations)
>
> 4.8. OAM
 >
> There have been no reports of NATs between the AFBRs (in the transit
> core) so a NAT detection solution is not needed.
>
> Other OAM needed features include:
>
> - Usage accounting
>
> - End-point failure detection (must be encapsulated w/in the tunnel
> in the transmitting direction
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 12]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> - Path failure detection)
>
> 4.9. Encapsulations
>
> IPv6/IPv4,IPv4/IPv6 and overlapping address space as defined in the
> L3VPN working group are on the critical path for softwires. Other
> encapsulations, like IPv4/IPv4 or IPLS as defined in the L2VPN
> working group, are nice to have but not on the critical path.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 13]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 5. Problems: Contrast & Compare
>
> An important distinction between the "Hub & Spokes" and " Mesh"
> problems is that the former defines client-initiated tunnels and the
> "spoke" is a device on the client premises (and may be owned by the
> client). The latter discusses about provider-initiated tunnels, and
> the devices participating in the mesh are on the provider premises
> and owned/managed by the provider.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 14]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> 6. Security Considerations
>
> None.
>
> 7. References
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 15]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> Authors' Addresses
>
> Xing Li
> CERNET
 > Room 225 Main Building, Tsinghua University
> Beijing 100084
> China
>
> Phone: +86 10 62785983
> Fax: +86 10 62785933
> Email: xing@cernet.edu.cn
>
>
> Alain Durand
> Comcast
> xxx
> xxx
> xxx
>
> Phone: xxx
> Fax: xxx
> Email: xxx
>
>
> Shin Miyakawa
> xxx
> xxx
> xxx
> xxx
>
> Phone: xxx
> Fax: xxx
> Email: xxx
>
>
> Jordi Palet Martinez
> Consulintel
> San Jose Artesano, 1
> Alcobendas - Madrid
> E-28108 - Spain
>
> Phone: +34 91 151 81 99
> Fax: +34 91 151 81 98
> Email: jordi.palet@consulintel.es
>
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 16]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> Florent Parent
> xxx
> xxx
> xxx
> xxx
>
> Phone: xxx
> Fax: xxx
> Email: xxx
>
> David Ward
> xxx
> xxx
> xxx
> xxx
>
> Phone: xxx
> Fax: xxx
> Email: xxx
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 17]
>
>
> Internet-Draft Softwire Problem Statement November 2005
>
>
> Intellectual Property Statement
>
> The IETF takes no position regarding the validity or scope of any
> Intellectual Property Rights or other rights that might be claimed to
> pertain to the implementation or use of the technology described in
> this document or the extent to which any license under such rights
> might or might not be available; nor does it represent that it has
> made any independent effort to identify any such rights. Information
> on the procedures with respect to rights in RFC documents can be
> found in BCP 78 and BCP 79.
>
> Copies of IPR disclosures made to the IETF Secretariat and any
> assurances of licenses to be made available, or the result of an
> attempt made to obtain a general license or permission for the use of
> such proprietary rights by implementers or users of this
> specification can be obtained from the IETF on-line IPR repository at
> http://www.ietf.org/ipr.
>
> The IETF invites any interested party to bring to its attention any
> copyrights, patents or patent applications, or other proprietary
> rights that may cover technology that may be required to implement
> this standard. Please address the information to the IETF at
> ietf-ipr@ietf.org.
>
>
> Disclaimer of Validity
>
> This document and the information contained herein are provided on an
> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 >
>
> Copyright Statement
>
> Copyright (C) The Internet Society (2005). This document is subject
> to the rights, licenses and restrictions contained in BCP 78, and
> except as set forth therein, the authors retain all their rights.
>
>
> Acknowledgment
>
> Funding for the RFC Editor function is currently provided by the
> Internet Society.
>
>
>
>
> Li, et al. Expires May 18, 2006 [Page 18]
>
>


The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

New Message Reply Date view Thread view Subject view Attachment view

This archive was generated by hypermail 2.1.7 : 12/01/06 EST