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

Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> Mon, 12 August 2013 19:30 UTC

Return-Path: <carlosm3011@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 2626F21F99A1 for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 12:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level:
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
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 OKd4AQIx+DOk for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 12:30:13 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A743921F997D for <v6ops@ietf.org>; Mon, 12 Aug 2013 12:30:12 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id t13so5098460lbd.2 for <v6ops@ietf.org>; Mon, 12 Aug 2013 12:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JG7/PKZ2HLF+pmP5X5ZQvi5iHUUzgkIrdivoJjENxQo=; b=cV89Q+AJ8SNx04fmph9uUF47P2FfsuNnl9MDw1JIo3Ijsr0+o18yHa1zPiLEIi9mih xQ+xz70LUNsrqwAqe3QM+ok9HOCi2mxuEIzOvKHp5EYWH8c4aDzMwfutv6cfZUHi0SwJ AMZp2/Y79Hr7UOmD6LrupnJwwinI8/WaECECm/aDGHu3zSLpddw7iJIGshFASgdz9fx4 OA1385zAl1NfXbmdmUC11A4z0VsxZa81mBgGOuQiaJd8DZbZvXub34fJ13zcbZNB5bec TzGlmKEutgNNFB1WK5iFWfblY520eELKhfEE9KVnJ5buA6xqDnXDAy2mDintt0TKpHy4 45AA==
MIME-Version: 1.0
X-Received: by 10.152.22.65 with SMTP id b1mr176786laf.46.1376335811380; Mon, 12 Aug 2013 12:30:11 -0700 (PDT)
Received: by 10.112.168.225 with HTTP; Mon, 12 Aug 2013 12:30:11 -0700 (PDT)
In-Reply-To: <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com>
References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com>
Date: Mon, 12 Aug 2013 16:30:11 -0300
Message-ID: <CA+z-_EWFAGFqyo3E3LzrEhpMRV6axdLJTC50BNwXMNGuJtZuTA@mail.gmail.com>
From: Carlos Martinez-Cagnazzo <carlosm3011@gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: multipart/alternative; boundary=089e0158b92a210b5704e3c527a1
Cc: Alejandro Acosta <aacosta@rocketmail.com>, "<v6ops@ietf.org>" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: carlos@lacnic.net
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, 12 Aug 2013 19:30:14 -0000

As far as I understand, Antonio does some training involving 6RD
deployments, where each 'team' needs its own /32. There might be other
cases though, like for example doing some work involving BGP routing
between different teams and for which you expect each one of them to carve
a /32.

For an IPv6 veteran, carving a /32 is no different from carving a /48 or
carving a /64 into smaller chunks. However, for newbies it just doesn't
work. Sure, each could work on 2001:db8, but then if you want to implement
such a plan on a live lab, you have a problem.

cheers,

~Carlos


On Mon, Aug 12, 2013 at 2:17 PM, Fred Baker (fred) <fred@cisco.com> 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 <moreiras@nic.br> wrote:
>
> > Hi.
> >
> > I would like to ask you to please review and comment the following draft:
> >
> > http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00
> >
> > 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]
> >
> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================