Document Action: 'Deployment Considerations for Dual-Stack Lite' to Informational RFC (draft-ietf-softwire-dslite-deployment-08.txt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The IESG has approved the following document:
- 'Deployment Considerations for Dual-Stack Lite'
  (draft-ietf-softwire-dslite-deployment-08.txt) as Informational RFC

This document is the product of the Softwires Working Group.

The IESG contact persons are Ralph Droms and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment/




Technical Summary 

   Dual-stack Lite (DS-Lite) [RFC6333] is a transition technique that
   enable operators to multiplex public IPv4 addresses while
   provisioning only IPv6 to users. This document discusses the
   deployment issues and describes requirements for the deployment and
   operation of Dual-Stack Lite.

Working Group Summary 

   This document was discussed in depth and well-reviewed.  WG
   consensus is strong to publish this document.

Document Quality 

   This is deployment discussion rather than a protocol definition,
   while DS-Lite has been deployed/tested in some production networks.

Personnel 

   Softwire co-chair, Yong Cui, is the Document Shepherd.  Ralph Droms
   is the Responsible AD.

RFC Editor Note

Please make the following changes when this document is published:

Section 2.6:

OLD:

   Alternatively, AFTR may perform accounting for IPv4 traffic.
   However, operators must be aware that this will introduce some
   challenges especially in DSL deployment.  In DSL deployment, the AAA
   transaction normally happens between the edge router (i.e., Broadband
   Network Gateway) and AAA server.  [RFC6333] does not require the AFTR
   to interact with the AAA server or edge router.  Thus, AFTR may not
   have the AAA parameters (e.g., Account Session ID) associated to
   users to generate IPv4 accounting record.  The accounting process at
   the AFTR is only necessary if the operator requires separating per
   user accounting records for IPv4 and IPv6 traffic.  If the per user
   IPv6 accounting records, collected by the edge router, are
   sufficient, and the additional complexity of enabling IPv4 accounting
   at the ATFR is not required.  It is important to notice that, since
   the IPv4 traffic is encapsulated in IPv6 packets, the data collected
   by the edge router for IPv6 traffic already contain the total amount
   of traffic (i.e.  IPv4 and IPv6).

NEW:

   Alternatively, AFTR may perform accounting for IPv4 traffic.
   However, operators must be aware that this will introduce some
   challenges especially in DSL deployment.  In DSL deployment, the
   AAA transaction normally happens between the edge router (i.e.,
   Broadband Network Gateway) and AAA server.  [RFC6333] does not
   require the AFTR to interact with the AAA server or edge router.
   Thus, AFTR may not have the AAA parameters (e.g., Account Session
   ID) associated to users to generate IPv4 accounting record.  IPv4
   traffic accounting at the AFTR is not recommended when the AAA
   parameters necessary to generate complete IPv4 accounting records
   are not available.  The accounting process at the AFTR is only
   necessary if the operator requires separating per user accounting
   records for IPv4 and IPv6 traffic.  If the per user IPv6 accounting
   records, collected by the edge router, are sufficient, and the
   additional complexity of enabling IPv4 accounting at the ATFR is
   not required.  It is important to notice that, since the IPv4
   traffic is encapsulated in IPv6 packets, the data collected by the
   edge router for IPv6 traffic already contain the total amount of
   traffic (i.e.  IPv4 and IPv6).

END

In section 3.2.2:

OLD:

   Operators should assign the same IPv4 address
   (i.e., 192.0.0.2/32) to all AFTRs.  IANA allocates 192.0.0.0/29
   [RFC6333] Section 5.7 that can be used for this purpose.

NEW:

   Operators should assign the same IPv4 address
   (e.g., 192.0.0.2/32 [RFC6333]) to all AFTRs.  IANA has allocated
   the 192.0.0.0/29 network prefix to provide IPv4 addresses for this
   purpose [RFC 6333].

END

Section 2.4:

OLD:

   AFTR is a NAT device.  It enables multiple users to share a single
   public IPv4 address.  [RFC6269] discusses some considerations when
   sharing an IPv4 address.  When a public IPv4 address is blacklisted
   by a remote peer, this may affect multiple B4 elements sharing the
   same IPv4 address.  Operators deploying DS-Lite should be aware that
   Internet hosts may rely solely on source IP address to identify an
   abusive household and may not be aware that a given single IPv4
   address is actually shared by multiple households.  A content
   provider may block services for a shared IPv4 address and this will
   impact all households sharing this particular IPv4 address.  The
   operator may receive calls of service outage and will need to take
   appropriate actions.  Such corrective actions include but not limited
   to notifying the content provider to combine the IPv4 address with
   transport (e.g., TCP) and application protocol (e.g., HTTP) to
   identify abusive household.  [RFC6302].
   [I-D.ietf-intarea-nat-reveal-analysis] analyzes different approaches
   to identify a user in a shared address environment.

NEW:

   AFTR is a NAT device.  It enables multiple users and/or hosts to
   share a single public IPv4 address.  [RFC6269] discusses some
   considerations when sharing an IPv4 address.  When a public IPv4
   address is blacklisted by a remote peer, this may affect multiple
   users or hosts.  Operators deploying DS-Lite should be aware that
   Internet hosts may not be aware that a given single IPv4 address is
   actually shared by multiple users or hosts.  A content provider
   might block services for a shared IPv4 address and this would then
   impact all users and hosts sharing this particular IPv4 address.
   The operator would be likely to receive calls related to service
   outage and would then need to take appropriate corrective actions
   re-establishing connectivity.

END


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux