Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

Owen DeLong <> Mon, 12 August 2013 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 784E121F9EA3 for <>; Mon, 12 Aug 2013 11:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JT8wz+GNW19C for <>; Mon, 12 Aug 2013 11:36:44 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id B8FA921F9E8B for <>; Mon, 12 Aug 2013 11:36:40 -0700 (PDT)
Received: from (delong-dhcp27 []) (authenticated bits=0) by (8.14.2/8.14.1) with ESMTP id r7CIVDb9014741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 11:31:14 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 r7CIVDb9014741
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=mail; t=1376332275; bh=jyCehuZiIAWMD4l6BVWEQWXjKKQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fwLpuJ8iGUgEf3oTnnuTANSODdOXmoHj+6VBR2hGA8PNzFYELZkhhN/cFPRi2fkBy nvQPL8xrgAORmw8MDhyP84xtf70WJvgK3YGEgm8cJpDd3fC7KinQxaDkPNI3lDudeo 97fRusVohQL8+7hW3VHqB10VlQTMvd1vlKBbKDEo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Mon, 12 Aug 2013 11:31:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "Fred Baker (fred)" <>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 ( []); Mon, 12 Aug 2013 11:31:15 -0700 (PDT)
Cc: Alejandro Acosta <>, "<>" <>
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Aug 2013 18:36:45 -0000

If you are trying to demonstrate or teach peerings across multiple ASNs and show examples of how multiple ISPs might carve up their /32s (or larger) differently, it's very hard to do all of that within a single /32.

Antonio and I do very similar types of training from the sounds of it and we have encountered the same issues.

A larger doc prefix would be useful. I don't see it as critical, but I don't see any significant reason not to do so. I understand the objection raised by Cameron, but, really, anything the IETF does likely creates some amount of work for operators. Thus is the nature of operating a network built on an evolving technology. You knew the job was dangerous when you took it.


On Aug 12, 2013, at 10:17 , "Fred Baker (fred)" <> wrote:

> Speaking as a chair, I don't have a problem with it being discussed in v6ops, but I think the issue belongs in 6man by charter.
> Speaking as a document author (think of RFCs 6052, 6144, 6145, 6146, and 6147, which I helped edit or write), I'm not sure I have ever had a case in which a /32 was not enough. I might, for example, need to use layers of prefixes like
>    2001:db8::/32
>    2001:db8:100::/40
>    2001:db8:202::/48
>    2001:db8:300:300::/56
>    2001:db8:400:440::/60
>    2001:db8:400:444::/64
> but I seem to have plenty of layers at my disposal. I'd be interested to understand the cases in which you find yourself cramped?
> On Aug 11, 2013, at 12:16 PM, Antonio M. Moreiras <> wrote:
>> Hi.
>> I would like to ask you to please review and comment the following draft:
>> It intends to ask IANA to reserve another IPv6 prefix for documentation.
>> Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago.
>> The prefix 2001:db8::/32 showed to be very useful. It is widely used.
>> But we are still facing the same problem that RFC 3849 tried to address:
>> in some kind of documents, tutorials and didactic laboratories, we have
>> been using other prefixes, because a /32 isn't enough to represent the
>> scenario.
>> We consider that a /20 would be enough.
>> If possible, we would like to ask IANA to reserve something easy to
>> remember, and self explaining, such as:
>> 2D0C::/20
>> but *this suggestion is not stated in the document*. This prefix is from
>> the global unicast space, and 2d00::/8 is currently marked as reserved
>> by IANA [1], so it would be possible. Anyway, we think it would be
>> better to discuss the question in the mailing-list.
>> Reviewing the archives from when draft-huston-ipv6-documentation-prefix
>> (that became RFC 3849) was being discussed, both questions (the
>> necessity of a larger prefix, or multiple prefixes, and the possibility
>> to reserve something easier to remember and self explaining) were
>> raised. I am not sure why none of them led to something concrete.
>> Probably because the draft just intended to document an allocation
>> already made by APNIC, and maybe it was not so clear then how useful it
>> would be.
>> If you agree in principle with the proposal, other point to discuss is
>> if this subject is compatible with v6ops. Maybe it should be addressed
>> in 6man, or other place.
>> Thanks.
>> Moreiras.
>> [1]
>> _______________________________________________
>> v6ops mailing list
> _______________________________________________
> v6ops mailing list