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

Owen DeLong <> Wed, 14 August 2013 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F62521F967C for <>; Wed, 14 Aug 2013 13:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id idFUTtxMwLha for <>; Wed, 14 Aug 2013 13:20:42 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 9045821F9CDF for <>; Wed, 14 Aug 2013 13:20:40 -0700 (PDT)
Received: from (delong-dhcp27 []) (authenticated bits=0) by (8.14.2/8.14.1) with ESMTP id r7EKHgdp016128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Aug 2013 13:17:43 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 r7EKHgdp016128
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=mail; t=1376511464; bh=9/qeqqPvaKZbauxCe3qHuCiQCNA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Yjjwf/qB/7HLhGrrwY7QT8I1khc+kBmv93KqNXY/KM9+dirPaYmVnr4LFP4U8b/bV 9hF2LXeaNqzeyr3b7Wu/YX92xSX5M+eSSnV8E0WxHMmTKp8vbyvONw3a3NuTDhUlKG ZGMNLFfH1+QVmiicHALXbYY7z2icxPbeCXYF6vTU=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Wed, 14 Aug 2013 13:17:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Mark ZZZ Smith <>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 ( []); Wed, 14 Aug 2013 13:17:44 -0700 (PDT)
Cc: "" <>
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: Wed, 14 Aug 2013 20:20:43 -0000

>>> [WEG] at the risk of debating bikeshed colors, I would suggest perhaps 
>> using :db8:: for both the proposed GUA and ULA doc prefixes so that it serves as 
>> a visual cue.
>> I have no problem with that.
>> How about 02db:8000::/20 and fc00:0db8::/32?
> As fc00:0db8::/32 is from within the existing but albeit unused portion of ULA prefix, any future use of fc00::/8 will need to specifically exclude it. I think exceptions to the normal case are better to avoid because they're another thing to remember, program as an exception case and therefore a prone to errors etc.

By definition, a documentation prefix is going to be an exception.

> I think it would be better to specify a documentation ULA prefix that has the nearly the properties as conventional ULAs, but doesn't fall within fc00::/7 (perhaps fe::/7 or something within it?). The only differences would be statements about no forwarding, no accepting routes etc.

That's an awful lot of space to devote to documentation. Personally, I thought a /32 was excessive for ULA. A 7 is ridiculous, IMHO.

> Ultimately though, I think it is fundamentally impossible to prevent something silly like using documentation prefixes on a production network, unless you use actually invalid IPv6 prefixes. The only way I can think of to do that would be by doing things such as adding invalid hexadecimal 'g-z' numbers into the example prefixes. I'm not sure I like the idea, although it might cause people who get tripped up on it to go back and think some more about what they're doing and put more effort into getting it right.

It is impossible to prevent. This aims to:

	1.	Make it less likely.
	2.	Make it easier to identify
	3.	Cause earlier identification (and thus easier rectification) when it does occur.

The doc prefix, in order to achieve full value, needs to be implementable in some training lab scenarios. As such, g-z would be a non-starter.