Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

Fred Baker <fred@cisco.com> Sun, 18 March 2012 23:39 UTC

Return-Path: <fred@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A066621F8546 for <v6ops@ietfa.amsl.com>; Sun, 18 Mar 2012 16:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmgF7VTUfRPy for <v6ops@ietfa.amsl.com>; Sun, 18 Mar 2012 16:39:16 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E48BD21F84F6 for <v6ops@ietf.org>; Sun, 18 Mar 2012 16:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=735918; q=dns/txt; s=iport; t=1332113956; x=1333323556; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=ZfK9wuq0VHmZyZWRcQYKy96vjOgLLpY5SuGYEL7vcDU=; b=KhwOZGSgTAsGikhHvRmzGXsuLlOVxmWNddrINvQJAFzjuIhtK0Bpa20P qZvFb5HuAU2TkSQabRgKRK4iU3I4UTdHTzIwDGCnuq1dWjkpIUJH7vMkk e9+7JldXJED3GbDSA2E8YeVRu5BqfeYusTq2voNQHKI+da7lvy1IF/J9l M=;
X-IronPort-AV: E=Sophos; i="4.73,608,1325462400"; d="scan'208,217"; a="34065219"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Mar 2012 23:39:14 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2INdB8m019096; Sun, 18 Mar 2012 23:39:11 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 18 Mar 2012 16:39:12 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 18 Mar 2012 16:39:12 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FF3@XMB-RCD-109.cisco.com>
Date: Sun, 18 Mar 2012 16:38:47 -0700
Message-Id: <BBD164AE-EA98-4C3F-BDBF-15681F70C124@cisco.com>
References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FF3@XMB-RCD-109.cisco.com>
To: Hemant Singh <shemant@cisco.com>
X-Mailer: Apple Mail (2.1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-42--528074175"
Cc: v6ops-chairs@tools.ietf.org, v6ops@ietf.org, Ron Bonica <ron@bonica.org>
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Mar 2012 23:39:17 -0000

THanks. I think there is room for discussion at IETF 83, and the opportunity for anyone who hasn't made his case to make it. I'd like to believe that we can send it to Ron after the meeting.

On Mar 16, 2012, at 6:48 AM, Hemant Singh (shemant) wrote:

> Folks,
>  
> Here is the delta between -07 that was sent out for LastCall and -08 which has edits from review.  Three minor items from Ole need closure during this week.   PCP needs closure between Med and Francis.   Changes from DanielR, RayH, and Ole have been incorporated.
>  
> Thanks,
>  
> Hemant
>  
> < draft-ietf-v6ops-6204bis-07.txt 
>  draft-ietf-v6ops-6204bis-08.txt >
>  
> Network Working Group                                           H. Singh
> Network Working Group                                           H. Singh
>  
> Internet-Draft                                                 W. Beebee
> Internet-Draft                                                 W. Beebee
>  
> Obsoletes: 6204 (if approved)                        Cisco Systems, Inc.
> Obsoletes: 6204 (if approved)                        Cisco Systems, Inc.
>  
> Intended status: Informational                                 C. Donley
> Intended status: Informational                                 C. Donley
>  
>  
> Expires: September 9, 2012                                    CableLabs
> Expires: September 17, 2012                                    CableLabs
>  
>                                                                 B. Stark
>                                                                 B. Stark
>  
>                                                                     AT&T
>                                                                     AT&T
>  
>                                                            O. Troan, Ed.
>                                                            O. Troan, Ed.
>  
>                                                      Cisco Systems, Inc.
>                                                      Cisco Systems, Inc.
>  
>  
>                                                            March 8, 2012
>                                                           March 16, 2012
>  
>  
>            Basic Requirements for IPv6 Customer Edge Routers
>            Basic Requirements for IPv6 Customer Edge Routers
>  
>  
>                       draft-ietf-v6ops-6204bis-07
>                       draft-ietf-v6ops-6204bis-08
>  
>  
> Abstract
> Abstract
>  
>  
>    This document specifies requirements for an IPv6 Customer Edge (CE)
>    This document specifies requirements for an IPv6 Customer Edge (CE)
>  
>    router.  Specifically, the current version of this document focuses
>    router.  Specifically, the current version of this document focuses
>  
>    on the basic provisioning of an IPv6 CE router and the provisioning
>    on the basic provisioning of an IPv6 CE router and the provisioning
>  
>    of IPv6 hosts attached to it.  The document also covers IP transition
>    of IPv6 hosts attached to it.  The document also covers IP transition
>  
>    technologies.  Two transition technologies in RFC 5969's 6rd and RFC
>    technologies.  Two transition technologies in RFC 5969's 6rd and RFC
>  
>    6333's DS-Lite. are covered in the document.  The document obsoletes
>    6333's DS-Lite. are covered in the document.  The document obsoletes
>  
>    RFC 6204, if approved.
>    RFC 6204, if approved.
>  
>  
>  
> skipping to change at page 1, line
> 42
>  
> skipping to change at page 1, line
> 42
>  
>    Internet-Drafts are working documents of the Internet Engineering
>    Internet-Drafts are working documents of the Internet Engineering
>  
>    Task Force (IETF).  Note that other groups may also distribute
>    Task Force (IETF).  Note that other groups may also distribute
>  
>    working documents as Internet-Drafts.  The list of current Internet-
>    working documents as Internet-Drafts.  The list of current Internet-
>  
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>  
>  
>    Internet-Drafts are draft documents valid for a maximum of six months
>    Internet-Drafts are draft documents valid for a maximum of six months
>  
>    and may be updated, replaced, or obsoleted by other documents at any
>    and may be updated, replaced, or obsoleted by other documents at any
>  
>    time.  It is inappropriate to use Internet-Drafts as reference
>    time.  It is inappropriate to use Internet-Drafts as reference
>  
>    material or to cite them other than as "work in progress."
>    material or to cite them other than as "work in progress."
>  
>  
>  
>    This Internet-Draft will expire on September 9, 2012.
>    This Internet-Draft will expire on September 17, 2012.
>  
>  
> Copyright Notice
> Copyright Notice
>  
>  
>    Copyright (c) 2012 IETF Trust and the persons identified as the
>    Copyright (c) 2012 IETF Trust and the persons identified as the
>  
>    document authors.  All rights reserved.
>    document authors.  All rights reserved.
>  
>  
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    This document is subject to BCP 78 and the IETF Trust's Legal
>  
>    Provisions Relating to IETF Documents
>    Provisions Relating to IETF Documents
>  
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    (http://trustee.ietf.org/license-info) in effect on the date of
>  
>    publication of this document.  Please review these documents
>    publication of this document.  Please review these documents
>  
>  
>  
> skipping to change at page 3, line
> 28
>  
> skipping to change at page 3, line
> 28
>  
>    of its LAN interfaces, and fetches other configuration information
>    of its LAN interfaces, and fetches other configuration information
>  
>    from the service provider network.  Automatic provisioning of more
>    from the service provider network.  Automatic provisioning of more
>  
>    complex topology than a single router with multiple LAN interfaces is
>    complex topology than a single router with multiple LAN interfaces is
>  
>    out of scope for this document.
>    out of scope for this document.
>  
>  
>    See [RFC4779] for a discussion of options available for deploying
>    See [RFC4779] for a discussion of options available for deploying
>  
>    IPv6 in service provider access networks.
>    IPv6 in service provider access networks.
>  
>  
>    The document also covers IP transition technologies.  Two transition
>    The document also covers IP transition technologies.  Two transition
>  
>    technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in
>    technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in
>  
>  
>    the document.  At the time of writing this document these were the
>    the document.
>  
>    only two transition technologies available in RFC form to be included
>  
>    in this document.
>  
>  
> 1.1.  Requirements Language
> 1.1.  Requirements Language
>  
>  
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  
>    document are to be interpreted as described in RFC 2119 [RFC2119].
>    document are to be interpreted as described in RFC 2119 [RFC2119].
>  
>  
> 2.  Terminology
> 2.  Terminology
>  
>  
>    End-User Network          one or more links attached to the IPv6 CE
>    End-User Network          one or more links attached to the IPv6 CE
>  
>  
>  
> skipping to change at page 9, line
> 8
>  
> skipping to change at page 9, line
> 8
>  
>            router MUST support IPv6 over PPP [RFC5072].
>            router MUST support IPv6 over PPP [RFC5072].
>  
>  
>    WLL-3:  If the WAN interface supports PPP encapsulation, in a dual-
>    WLL-3:  If the WAN interface supports PPP encapsulation, in a dual-
>  
>            stack environment with IPCP and IPV6CP running over one PPP
>            stack environment with IPCP and IPV6CP running over one PPP
>  
>            logical channel, the Network Control Protocols (NCP's) MUST
>            logical channel, the Network Control Protocols (NCP's) MUST
>  
>            be treated as independent of each other and start and
>            be treated as independent of each other and start and
>  
>            terminate independently.
>            terminate independently.
>  
>  
>    Address assignment requirements:
>    Address assignment requirements:
>  
>  
>  
>    WAA-1:  The IPv6 CE router MUST support Stateless Address
>    WAA-1:   The IPv6 CE router MUST support Stateless Address
>  
>            Autoconfiguration (SLAAC) [RFC4862].
>             Autoconfiguration (SLAAC) [RFC4862].
>  
>  
>  
>    WAA-2:  The IPv6 CE router MUST follow the recommendations in Section
>    WAA-2:   The IPv6 CE router MUST follow the recommendations in
>  
>            4 of [RFC5942], and in particular the handling of the L flag
>             Section 4 of [RFC5942], and in particular the handling of
>  
>            in the Router Advertisement Prefix Information option.
>             the L flag in the Router Advertisement Prefix Information
>  
>             option.
>  
>  
>  
>    WAA-3:  The IPv6 CE router MUST support DHCPv6 [RFC3315] client
>    WAA-3:   The IPv6 CE router MUST support DHCPv6 [RFC3315] client
>  
>            behavior.
>             behavior.
>  
>  
>  
>    WAA-4:  The IPv6 CE router MUST be able to support the following
>    WAA-4:   The IPv6 CE router MUST be able to support the following
>  
>            DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and
>             DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and
>  
>            DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able to
>             DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able to
>  
>            support the DNS Search List DNSSL option as specified in
>             support the DNS Search List DNSSL option as specified in
>  
>            [RFC3646].
>             [RFC3646].
>  
>  
>  
>    WAA-5:  The IPv6 CE router SHOULD support the DHCPv6 Simple Network
>    WAA-5:   The IPv6 CE router SHOULD implement the Simple Network Time
>  
>            Time Protocol (SNTP) option [RFC4075] and theInformation
>             Protocol (SNTP) as specified in [RFC2030].  If the CE router
>  
>            Refresh Time option [RFC4242].
>             implements SNTP, it requests the SNTP option [RFC4075] and
>  
>             uses the received list of servers as primary time reference,
>  
>             unless explicitly configured otherwise.
>  
>  
>  
>    WAA-6:  If the IPv6 CE router receives a Router Advertisement message
>    WAA-6:   The IPv6 CE router SHOULD implement the Information Refresh
>  
>            (described in [RFC4861]) with the M flag set to 1, the IPv6
>             Time option and associated client behavior as specified in
>  
>            CE router MUST do DHCPv6 address assignment (request an IA_NA
>             [RFC4242].
>  
>            option).
>  
>  
>  
>    WAA-7:  If the IPv6 CE router does not acquire global IPv6
>    WAA-7:   If the IPv6 CE router receives a Router Advertisement
>  
>            address(es) from either SLAAC or DHCPv6, then it MUST create
>             message (described in [RFC4861]) with the M flag set to 1,
>  
>            global IPv6 address(es) from its delegated prefix(es) and
>             the IPv6 CE router MUST do DHCPv6 address assignment
>  
>            configure those on one of its internal virtual network
>             (request an IA_NA option).
>  
>            interfaces, unless configured to require a global IPv6
>  
>            address on the WAN interface.
>  
>  
>  
>    WAA-8:  The CE Router MUST support the DHCPv6 SOL_MAX_RT option
>    WAA-8:   If the IPv6 CE router does not acquire global IPv6
>  
>            [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
>             address(es) from either SLAAC or DHCPv6, then it MUST create
>  
>            Advertise or Reply message and set its internalSOL_MAX_RT
>             global IPv6 address(es) from its delegated prefix(es) and
>  
>            parameter to the value contained in the SOL_MAX_RT option.
>             configure those on one of its internal virtual network
>  
>             interfaces, unless configured to require a global IPv6
>  
>             address on the WAN interface.
>  
>  
>  
>    WAA-9:  As a router, the IPv6 CE router MUST follow the weak host
>    WAA-9:   The CE Router MUST support the DHCPv6 SOL_MAX_RT option
>  
>            (Weak ES) model [RFC1122].  When originating packets from an
>             [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
>  
>            interface, it will use a source address from another one of
>             Advertise or Reply message and set its internal SOL_MAX_RT
>  
>            its interfaces if the outgoing interface does not have an
>             parameter to the value contained in the SOL_MAX_RT option.
>  
>            address of suitable scope.
>  
>    WAA-10:  As a router, the IPv6 CE router MUST follow the weak host
>  
>             (Weak ES) model [RFC1122].  When originating packets from an
>  
>             interface, it will use a source address from another one of
>  
>             its interfaces if the outgoing interface does not have an
>  
>             address of suitable scope.
>  
>  
>    Prefix delegation requirements:
>    Prefix delegation requirements:
>  
>  
>    WPD-1:  The IPv6 CE router MUST support DHCPv6 prefix delegation
>    WPD-1:  The IPv6 CE router MUST support DHCPv6 prefix delegation
>  
>            requesting router behavior as specified in [RFC3633] (IA_PD
>            requesting router behavior as specified in [RFC3633] (IA_PD
>  
>  
>            option).  The IPv6 CE Router SHOULD support the
>            option).
>  
>                                                                          
>  
>    WPD-2:  The IPv6 CE Router SHOULD support the
>  
>            [I-D.ietf-dhc-pd-exclude] PD-Exclude option.
>            [I-D.ietf-dhc-pd-exclude] PD-Exclude option.
>  
>  
>  
>    WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
>    WPD-3:  The IPv6 CE router MAY indicate as a hint to the delegating
>  
>            router the size of the prefix it requires.  If so, it MUST
>            router the size of the prefix it requires.  If so, it MUST
>  
>            ask for a prefix large enough to assign one /64 for each of
>            ask for a prefix large enough to assign one /64 for each of
>  
>            its interfaces, rounded up to the nearest nibble, and SHOULD
>            its interfaces, rounded up to the nearest nibble, and SHOULD
>  
>            be configurable to ask for more.
>            be configurable to ask for more.
>  
>  
>  
>    WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
>    WPD-4:  The IPv6 CE router MUST be prepared to accept a delegated
>  
>            prefix size different from what is given in the hint.  If the
>            prefix size different from what is given in the hint.  If the
>  
>            delegated prefix is too small to address all of its
>            delegated prefix is too small to address all of its
>  
>            interfaces, the IPv6 CE router SHOULD log a system management
>            interfaces, the IPv6 CE router SHOULD log a system management
>  
>  
>            error.
>            error.  [RFC6177] covers the recommendations for service
>  
>            providers for prefix allocation sizes.
>  
>  
>  
>    WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
>    WPD-5:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
>  
>            delegation when either the M or O flags are set to 1 in a
>            delegation when either the M or O flags are set to 1 in a
>  
>            received Router Advertisement message.
>            received Router Advertisement message.
>  
>  
>  
>    WPD-5:  If the delegated prefix(es) are aggregate route(s) of
>    WPD-6:  If the delegated prefix(es) are aggregate route(s) of
>  
>            multiple, more-specific routes, the IPv6 CE router MUST
>            multiple, more-specific routes, the IPv6 CE router MUST
>  
>            discard packets that match the aggregate route(s), but not
>            discard packets that match the aggregate route(s), but not
>  
>            any of the more-specific routes.  In other words, the next
>            any of the more-specific routes.  In other words, the next
>  
>            hop for the aggregate route(s) should be the null
>            hop for the aggregate route(s) should be the null
>  
>            destination.  This is necessary to prevent forwarding loops
>            destination.  This is necessary to prevent forwarding loops
>  
>            when some addresses covered by the aggregate are not
>            when some addresses covered by the aggregate are not
>  
>            reachable [RFC4632].
>            reachable [RFC4632].
>  
>  
>            (a)  The IPv6 CE router SHOULD send an ICMPv6 Destination
>            (a)  The IPv6 CE router SHOULD send an ICMPv6 Destination
>  
>                 Unreachable message in accordance with Section 3.1 of
>                 Unreachable message in accordance with Section 3.1 of
>  
>                 [RFC4443] back to the source of the packet, if the
>                 [RFC4443] back to the source of the packet, if the
>  
>                 packet is to be dropped due to this rule.
>                 packet is to be dropped due to this rule.
>  
>  
>  
>    WPD-6:  If the IPv6 CE router requests both an IA_NA and an IA_PD
>    WPD-7:  If the IPv6 CE router requests both an IA_NA and an IA_PD
>  
>            option in DHCPv6, it MUST accept an IA_PD option in DHCPv6
>            option in DHCPv6, it MUST accept an IA_PD option in DHCPv6
>  
>            Advertise/Reply messages, even if the message does not
>            Advertise/Reply messages, even if the message does not
>  
>            contain any addresses, unless configured to only obtain its
>            contain any addresses, unless configured to only obtain its
>  
>            WAN IPv6 address via DHCPv6.
>            WAN IPv6 address via DHCPv6.
>  
>  
>  
>    WPD-7:  By default, an IPv6 CE router MUST NOT initiate any dynamic
>    WPD-8:  By default, an IPv6 CE router MUST NOT initiate any dynamic
>  
>            routing protocol on its WAN interface.
>            routing protocol on its WAN interface.
>  
>  
> 4.3.  LAN-Side Configuration
> 4.3.  LAN-Side Configuration
>  
>  
>    The IPv6 CE router distributes configuration information obtained
>    The IPv6 CE router distributes configuration information obtained
>  
>    during WAN interface provisioning to IPv6 hosts and assists IPv6
>    during WAN interface provisioning to IPv6 hosts and assists IPv6
>  
>    hosts in obtaining IPv6 addresses.  It also supports connectivity of
>    hosts in obtaining IPv6 addresses.  It also supports connectivity of
>  
>    these devices in the absence of any working WAN interface.
>    these devices in the absence of any working WAN interface.
>  
>  
>    An IPv6 CE router is expected to support an IPv6 end-user network and
>    An IPv6 CE router is expected to support an IPv6 end-user network and
>  
>  
>  
> skipping to change at page 16, line
> 28
>  
> skipping to change at page 16, line
> 29
>  
>               draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in
>               draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in
>  
>               progress), November 2011.
>               progress), November 2011.
>  
>  
>    [I-D.ietf-dhc-pd-exclude]
>    [I-D.ietf-dhc-pd-exclude]
>  
>               Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
>               Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
>  
>               "Prefix Exclude Option for DHCPv6-based Prefix
>               "Prefix Exclude Option for DHCPv6-based Prefix
>  
>               Delegation", draft-ietf-dhc-pd-exclude-04 (work in
>               Delegation", draft-ietf-dhc-pd-exclude-04 (work in
>  
>               progress), December 2011.
>               progress), December 2011.
>  
>  
>    [I-D.ietf-pcp-base]
>    [I-D.ietf-pcp-base]
>  
>  
>               Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R.
>               Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
>  
>               Penno, "Port Control Protocol (PCP)",
>               Selkirk, "Port Control Protocol (PCP)",
>  
>               draft-ietf-pcp-base-23 (work in progress), February2012.
>               draft-ietf-pcp-base-24 (work in progress), March 2012.
>  
>  
>    [RFC1122]  Braden, R., "Requirements for Internet Hosts -
>    [RFC1122]  Braden, R., "Requirements for Internet Hosts -
>  
>               Communication Layers", STD 3, RFC 1122, October 1989.
>               Communication Layers", STD 3, RFC 1122, October 1989.
>  
>  
>  
>    [RFC2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
>  
>               for IPv4, IPv6 and OSI", RFC 2030, October 1996.
>  
>                                                                          
>  
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>  
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>  
>  
>    [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
>    [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
>  
>               RFC 2131, March 1997.
>               RFC 2131, March 1997.
>  
>  
>    [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
>    [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
>  
>               Networks", RFC 2464, December 1998.
>               Networks", RFC 2464, December 1998.
>  
>  
>    [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
>    [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
>  
>  
>  
> skipping to change at page 18, line
> 25
>  
> skipping to change at page 18, line
> 30
>  
>  
>    [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
>    [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
>  
>               Infrastructures (6rd) -- Protocol Specification",
>               Infrastructures (6rd) -- Protocol Specification",
>  
>               RFC 5969, August 2010.
>               RFC 5969, August 2010.
>  
>  
>    [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in
>    [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in
>  
>               Customer Premises Equipment (CPE) for Providing
>               Customer Premises Equipment (CPE) for Providing
>  
>               Residential IPv6 Internet Service", RFC 6092,
>               Residential IPv6 Internet Service", RFC 6092,
>  
>               January 2011.
>               January 2011.
>  
>  
>  
>    [RFC6177]  Narten, T., Huston, G., and L. Roberts, "IPv6 Address
>  
>               Assignment to End Sites", BCP 157, RFC 6177, March 2011.
>  
>                                                                          
>  
>    [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
>    [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
>  
>               Stack Lite Broadband Deployments Following IPv4
>               Stack Lite Broadband Deployments Following IPv4
>  
>               Exhaustion", RFC 6333, August 2011.
>               Exhaustion", RFC 6333, August 2011.
>  
>  
>    [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
>    [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
>  
>               Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
>               Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
>  
>               RFC 6334, August 2011.
>               RFC 6334, August 2011.
>  
>  
>    [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
>    [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
>  
>               Requirements", RFC 6434, December 2011.
>               Requirements", RFC 6434, December 2011.
>  
>  
>  
>  End of changes. 25 change
> blocks. 
>  
> 52 lines changed or deleted
>  
> 66 lines changed or added
>  
> 
> This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
>  
>  
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops