IETF Logo Mail Archive

Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

jouni korhonen <jouni.nospam@gmail.com> Thu, 01 December 2011 10:14 UTC

Return-Path: <jouni.nospam@gmail.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 4BFB121F8C49 for <v6ops@ietfa.amsl.com>; Thu, 1 Dec 2011 02:14:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.959
X-Spam-Level:
X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 mpiFhzbl6Hxf for <v6ops@ietfa.amsl.com>; Thu, 1 Dec 2011 02:13:59 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91A6721F8C3F for <v6ops@ietf.org>; Thu, 1 Dec 2011 02:13:59 -0800 (PST)
Received: by eabm6 with SMTP id m6so2211945eab.31 for <v6ops@ietf.org>; Thu, 01 Dec 2011 02:13:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=muRQXNJZo0G0O4QYwLzFoffAl/zp/kGmpHJfwPpbrCI=; b=DK5n/fuLihFHKfb9EQmFfr6rHsSkhrUdVS26XSuX40csGxWTSSFeuG8jBGnEB4q0K9 +vSuukHWflYCrTqDINDm7L+P1nVaf85BgIRkFCwS8A+hVB/2NQyMCMOKO+2/XmqKlFLd 2/tLXN+4Jw9b4+0MPEVX35ijg1DiLNY6SR0hc=
Received: by 10.180.80.98 with SMTP id q2mr4327859wix.53.1322734437368; Thu, 01 Dec 2011 02:13:57 -0800 (PST)
Received: from [10.255.128.228] ([192.100.123.77]) by mx.google.com with ESMTPS id gd6sm5422910wbb.1.2011.12.01.02.13.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 02:13:54 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <CAKD1Yr0-_Nq0dSSCengxAmgYRGuinZsw1wK-10uVL7ZYT+kRSg@mail.gmail.com>
Date: Thu, 01 Dec 2011 12:13:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F38860B-C948-4C8D-B92B-F420647CAE30@gmail.com>
References: <CAF26956.183598%wbeebee@cisco.com> <DE98E6AF-ACCF-430F-A97C-B36EF89DBB88@gmail.com> <DDBA2068-F8B6-460E-BE50-8399D03831A5@employees.org> <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <EDCECAAA-E83D-4F4F-8B3F-155E524FA6E6@employees.org> <E4D75382-2EB7-4B43-956D-31A7D4A152F5@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <D6395FF4-5875-4127-80D7-D9ECE468D023@gmail.com> <CAKD1Yr165Q7tz7-haWNFdcvJ4OX6wCUMNJnK5nfbUDrc3xEMWA@mail.gmail.com> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <CAKD1Yr0-_Nq0dSSCengxAmgYRGuinZsw1wK-10uVL7ZYT+kRSg@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
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: Thu, 01 Dec 2011 10:14:00 -0000

Lorenzo,

We got into this by the gentle guidance form IETF how to do it. It was quite a long ago already.. and discussed quite extensively in DHC WG. Now also part of Rel-10 in 3GPP.

- Jouni

On Nov 30, 2011, at 10:12 PM, Lorenzo Colitti wrote:

> On Wed, Nov 30, 2011 at 12:03, Vízdal Aleš <ales.vizdal@t-mobile.cz> wrote:
> the Prefix Delegation RFC 3633 states a limitation in section 12.1 that 'a prefix delegated to a requesting router cannot be used by the delegating router'. This limitation is a problem for the 3GPP case where they have standardised that the link prefix (/64) and the delegated prefix shall be aggregatable to a single prefix. So, you can use pd-exclude to signal the prefix part
> 
> in use.
> 
> 
> Fine, but if the only problem is that text, then why do we need a new option? Can't we just say somewhere that if the part of the prefix is used to connect the requesting router to the network, then the network MUST signal that to the client using some other means such as an RA?

v2.23.0 | Report a Bug | By Email