[pcp] #71 (dslite): Handling change of B4's IPv6 address

"pcp issue tracker" <trac@tools.ietf.org> Thu, 27 February 2014 22:46 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: pcp issue tracker <trac@tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: draft-ietf-pcp-dslite@tools.ietf.org, mohamed.boucadair@orange.com
Date: Thu, 27 Feb 2014 22:45:51 -0000
Message-ID: <066.da9f39acbb4f0e726165162172cd1c41@tools.ietf.org>
Resent-To: fdupont@isc.org, jacni@jacni.com, mrw@painless-security.com, tina.tsou.zouting@huawei.com, zhangdacheng@huawei.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/IHQU5qnoxYTpM0O-3Ld0LdM3PHU
Cc: pcp@ietf.org
Subject: [pcp] #71 (dslite): Handling change of B4's IPv6 address

#71: Handling change of B4's IPv6 address

 [DSlite portion of ticket #34 moved to this ticket]

 ======
 2.5. Change of the CPE WAN IP Address

    The change of the IP address of the WAN interface of the CPE would
    have an impact on the accuracy of the mappings instantiated in the
    PCP Server:

    o  For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new
       IPv6 address is used by the B4 element when encapsulating IPv4
       packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP
       Client is embedded in the B4, the refresh operation is triggered
       by the change of the B4 IPv6 address.  This would be more
       complicated when the PCP Client is located in a device behind the
       B4.

          [Ed.  Note: how an IPv4 host behind a DS-Lite CPE is aware that
          a new IPv6 address is used by the B4?]

    o  For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any
       change of the assigned IPv6 prefix delegated to the CPE will be
       detected by the PCP Client (because this leads to the allocation
       of a new IPv6 address).  The PCP Client has to undertake the
       operation described in Section 2.4.
 ========

 An issue is still unsolved in the DS-Lite case where the PCP client is not
 co-located with B4. This issue is not solved in the base PCP spec, but is
 addressed in this individual draft: http://tools.ietf.org/search/draft-
 vinapamula-softwire-dslite-prefix-binding-01

 The recommendation in http://tools.ietf.org/search/draft-vinapamula-
 softwire-dslite-prefix-binding-01 covers the PCP case, in particular these
 two recommendations:

    3.  In the event a new IPv6 address is assigned to B4, the AFTR
        SHOULD migrate existing state to be bound to the new B4's IP
        address.  This ensures the traffic destined to the previous IPv6
        address will redirected to the new IPv6 address.  The destination
        address for tunneling return traffic SHOULD be the last seen
        address from the CPE.  The source address of the tunnel would
        remain same as AFTR.

    4.  In the event of change of the CPE WAN IPv6 prefix, unsolicited
        PCP ANNOUNCE messages SHOULD be sent by the B4 element to
        internal hosts to update their mappings.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-pcp-
  mohamed.boucadair@orange.com       |  dslite@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  dslite                   |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/pcp/trac/ticket/71>
pcp <http://tools.ietf.org/pcp/>

[pcp] #71 (dslite): Handling change of B4's IPv6 … pcp issue tracker