Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

Wuyts Carl <Carl.Wuyts@technicolor.com> Mon, 25 November 2013 13:43 UTC

Return-Path: <Carl.Wuyts@technicolor.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67071AD69E; Mon, 25 Nov 2013 05:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFA36XASJWof; Mon, 25 Nov 2013 05:43:49 -0800 (PST)
Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 082B51ACCE3; Mon, 25 Nov 2013 05:43:46 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKUpNT+0Owgh/QX+ogaNa0yybGEQ1Ml2x0@postini.com; Mon, 25 Nov 2013 05:43:49 PST
Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 25 Nov 2013 14:39:16 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Mon, 25 Nov 2013 14:39:17 +0100
From: Wuyts Carl <Carl.Wuyts@technicolor.com>
To: Victor Kuarsingh <victor@jvknet.com>
Date: Mon, 25 Nov 2013 14:39:16 +0100
Thread-Topic: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers
Thread-Index: Ac7p406OXByR0Sn2S4i0S7kayo08eQAAC6lg
Message-ID: <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com>
References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <CAJc3aaPmsxTewQFznXo1GMao_pEpGicqoGk6ijfBjHOW-6sovw@mail.gmail.com>
In-Reply-To: <CAJc3aaPmsxTewQFznXo1GMao_pEpGicqoGk6ijfBjHOW-6sovw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_3135C2851EB6764BACEF35D8B495596806FB9EEDEDMOPESMBX01eut_"
MIME-Version: 1.0
Cc: "drafts-update-ref@iana.org" <drafts-update-ref@iana.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "rfc-dist@rfc-editor.org" <rfc-dist@rfc-editor.org>, "ietf-announce@ietf.org" <ietf-announce@ietf.org>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 25 Nov 2013 13:43:53 -0000

HI Victor,

Indeed, this will not be always known upfront.  Besides that, if you purely want to look at all active interfaces, I believe you will be (for residential market at least) push for a /64 for all deployments, and I don't believe this should be the goal.  After all, many residential scenario's at our customer base are a single LAN from defs....

regs

From: Victor Kuarsingh [mailto:victor@jvknet.com]
Sent: maandag 25 november 2013 14:36
To: Wuyts Carl
Cc: rfc-editor@rfc-editor.org; ietf-announce@ietf.org; rfc-dist@rfc-editor.org; drafts-update-ref@iana.org; v6ops@ietf.org
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

Carl,

Are you saying that vendors will be unable to determine the number of [local] interfaces during this initialization step?  As for "what is too small", is WPD-2 not sufficient in determining that?


   WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating

           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

           its interfaces, rounded up to the nearest nibble, and SHOULD

           be configurable to ask for more.

As for changes after initial IA_PD, are you concerned about new interfaces coming up on the box after IPv6 initialization?  If so, should those not be part of the PD size request upfront? E.g. Ask for /64 for all active and inactive interfaces.

regards,

Victor K

On Mon, Nov 25, 2013 at 7:54 AM, Wuyts Carl <Carl.Wuyts@technicolor.com<mailto:Carl.Wuyts@technicolor.com>> wrote:
All,
I can still see it is impossible today to fully comply to this as, IMHO,  the following requirement is impossible to meet (the SHOULD part):
""
WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
           prefix size different from what is given in the hint.  If the
           delegated prefix is too small to address all of its
           interfaces, the IPv6 CE router SHOULD log a system management
           error.  [RFC6177] covers the recommendations for service
           providers for prefix allocation sizes.
""
Checking if a ia_Pd is "too small" is impossible, i.e., what is "too small" ?  What if certain changes are done after initial ia_pd ?  What .... ?

Regs
Carl


-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>] On Behalf Of rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>
Sent: vrijdag 22 november 2013 19:33
To: ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>; rfc-dist@rfc-editor.org<mailto:rfc-dist@rfc-editor.org>
Cc: drafts-update-ref@iana.org<mailto:drafts-update-ref@iana.org>; v6ops@ietf.org<mailto:v6ops@ietf.org>; rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>
Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

A new Request for Comments is now available in online RFC libraries.


        RFC 7084

        Title:      Basic Requirements for IPv6 Customer
                    Edge Routers
        Author:     H. Singh, W. Beebee,
                    C. Donley, B. Stark
        Status:     Informational
        Stream:     IETF
        Date:       November 2013
        Mailbox:    shemant@cisco.com<mailto:shemant@cisco.com>,
                    wbeebee@cisco.com<mailto:wbeebee@cisco.com>,
                    c.donley@cablelabs.com<mailto:c.donley@cablelabs.com>,
                    barbara.stark@att.com<mailto:barbara.stark@att.com>
        Pages:      21
        Characters: 46569
        Obsoletes:  RFC 6204

        I-D Tag:    draft-ietf-v6ops-6204bis-12.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7084.txt

This document specifies requirements for an IPv6 Customer Edge (CE) router.  Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.  The document also covers IP transition technologies.  Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document.  The document obsoletes RFC 6204.

This document is a product of the IPv6 Operations Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>.  Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops