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

Mark ZZZ Smith <> Thu, 15 August 2013 07:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00AB021E8118 for <>; Thu, 15 Aug 2013 00:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DZ01XeyT0WjD for <>; Thu, 15 Aug 2013 00:33:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B7F621E8116 for <>; Thu, 15 Aug 2013 00:33:52 -0700 (PDT)
Received: from [] by with NNFMP; 15 Aug 2013 07:33:51 -0000
Received: from [] by with NNFMP; 15 Aug 2013 07:33:51 -0000
Received: from [] by with NNFMP; 15 Aug 2013 07:33:51 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 18466 invoked by uid 60001); 15 Aug 2013 07:33:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1376552030; bh=GOXfdpBR/7d2i9zadP5s/gNYIUnTzara57tnY9vgJhE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xi6Ld76Jk5NXAszFo/18xAKvRUdBYgki+2HBe57+qWSodqwIAj97Ska4Vegk7d8Ysg4Zf9W+OcyQPBUj35KT0/EAflO7Hj2hIEV7wqLh0F0FN7Qe6fL1IWkEMapeGXPB5Ntp1oBpaCayhIQ3Gb15WNwmA93UfpSOnAMMrUznzRY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T4WtnO7lgjiE0XvP0X7q0C0eCjy0CPbR+syxzJjxfXxFwrU2XsqqzbZelWq2pSvBhNgQoJaRDn7KjsurCWnEVTWmwNWJU+f47Mxhw+Ei1DjDe7158aOyk8HeKO+Z/f7SNocjpnMtIe8KkIWmwZ2oKj+YVjvUUlilPZRzaYx53N4=;
X-YMail-OSG: MSfQoPgVM1lqWqU1okv133g7HK3AukkE.1G8i1_dcrdzj5C bMy0KC8dlVNGExHek6xHAiLJlktDAXFkHOEvG2r81gSNPOHLYltsnlgFDblS jqMDPvBY0Y_4vV2Tc8zhcSYHIc_NumhgKZywPHAyDBsPBycovih2UoGtO7vz 1eLSYbPjNuKs428qqxzK.JLNoGjaSsyO_0HnEfC7oCp9TZuGh0B6Q9uj1RlO BmEm9lvfMFynozhN2nLI6Bp0ebmEfW4EB_KvNYdi7OJkG49SWm40o6xFiHMx LItCmkrxYPxGNER8ihbOFeiUjLGthm31OgW2MzXZP5Y47SZMQ7YUFwHmsjYv C7sYl02kgZ5kcisq.Sx5uHBQZL3GR7X2mBawMbHyw4eJ7jjavy5PqCC_vWcp rNkTae6k7qW7raiWSQbVb8bx.ntnbuDekDc.2twvWus.mQcRQTTF.O5ZfT7u DJKRdxvjmZmnZU3M8Wqsym54FD93v0x0xIxdw_IawV2TyEoaSJP9r2wx.KYt liAaIHAgee1TknjcszLrAdy2xWiE1yLIF0ZQ35NBJAlz1eH_NLCok22k3G46 uswwXMZvKVfaLWDI4Y5E7.FwTbd3m7H6oGo0-
Received: from [] by via HTTP; Thu, 15 Aug 2013 00:33:50 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBDYzogIkdlb3JnZSwgV2VzIiA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT47ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFRodXJzZGF5LCAxNSBBdWd1c3QgMjAxMyA2OjE3IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtbW9yZWlyYXMtdjZvcHMtcmYBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Thu, 15 Aug 2013 00:33:50 -0700 (PDT)
From: Mark ZZZ Smith <>
To: Owen DeLong <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Aug 2013 07:33:58 -0000

----- Original Message -----
> From: Owen DeLong <>
> To: Mark ZZZ Smith <>
> Cc: "George, Wes" <>om>; "" <>
> Sent: Thursday, 15 August 2013 6:17 AM
> Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
>>>>  [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.

Yes, but there has to be code to except it when it is being generated, recorded, precluded from ACLs etc. If fc00:0db8::/32 was used, then a potential future registry would have to exclude that range of prefixes, and assuming the operational rules are applied, then there would be mixed cases where parts of fc00::/8 are permitted/accepted/forwarded and then fc00:0db8::/32 has to either explicitly or implicitly denied/filtered/blocked. I think it is better to make the network's handling of all prefixes within fc00::/8 consistent, with no exceptions.

>>  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.

I agree the /7 is large and excessive, and I'm not really advocating for it. I suggested fe::/7 only to make a documentation ULA look similar to and adjacent to the existing non-documentation ULA space, rather than falling within the existing ULA space. Choosing to use a /7 for a documentation ULA would obviously need a lot of thought and justification, and I wouldn't think it'd be likely to be accepted. 

>>  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

This is the key reason I think outside of fc00::/7 would be better.

>     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.

If it is a documentation prefix then I think it should never be implemented in training labs, otherwise it is now more than just a documentation prefix. For a lab, standard ULA prefixes should do fine, and the exercise of students generating and deploying a conventional ULA prefix for their own network would be a good one to teach them how ULAs are to be properly generated and used.

> As such, g-z would be a non-starter.


I do agree it's not the greatest idea, but it would ensure the prefix can only be used in documentation and nothing else, and would facilitate training people on paper in how to subnet ULA-like space. After they've had that training they could then use real ULAs to implement a subnetting plan in their lab scenarios.