Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2

"Fred Baker (fred)" <fred@cisco.com> Sat, 28 June 2014 00:58 UTC

Return-Path: <fred@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFBA1A024F for <v6ops@ietfa.amsl.com>; Fri, 27 Jun 2014 17:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.552
X-Spam-Level:
X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUbx1gH-Misj for <v6ops@ietfa.amsl.com>; Fri, 27 Jun 2014 17:58:11 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30481A024B for <v6ops@ietf.org>; Fri, 27 Jun 2014 17:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2938; q=dns/txt; s=iport; t=1403917091; x=1405126691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yf/6bEsCdYU3c9bkfovvXz4C4IDwUNTt/PlH4Ri3M6k=; b=WJLgWC5LahaPs8hCVi5ruhhCF3gwP6OnzITUUs5YHHCQVyi1yZe2RFtO YwsZy7n3NCU5rxvpJsbW5Ag1FMNaHnKJWrZRMWdgpor87piRL5ClP4rjx Uu6WViEVrtTUUGBJ23R90qLCAf+iwaqxSFpDGafT7lho9kDUUuNixT82K 0=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAP0RrlOtJA2H/2dsb2JhbABAGoMNUk0NxEQBgQ0WdYQDAQEBAwFoEQULAgEIRjIlAgQOBQ6ILAgNNsQOF4tigyMHgy2BFgWSD4FChwyBRpI1g0JsgUQ
X-IronPort-AV: E=Sophos;i="5.01,565,1400025600"; d="asc'?scan'208";a="336269594"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jun 2014 00:58:10 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5S0w9I8013695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Jun 2014 00:58:09 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 19:58:09 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: "Shishio Tsuchiya (shtsuchi)" <shtsuchi@cisco.com>
Thread-Topic: [v6ops] JANOG34 provides 3.2.1 and 3.2.2
Thread-Index: AQHPkmwHurzZcJqO1EuYF7jyXqLTzA==
Date: Sat, 28 Jun 2014 00:58:09 +0000
Message-ID: <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com>
References: <53AD471B.6070009@cisco.com>
In-Reply-To: <53AD471B.6070009@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.116]
Content-Type: multipart/signed; boundary="Apple-Mail=_B91C49F0-CF9B-4062-9F10-44387270B780"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BDTETaZI2pFZT0dJf479RkNPaCI
Cc: "kshimizu@juniper.net" <kshimizu@juniper.net>, "v6ops@ietf.org" <v6ops@ietf.org>, "i18n@janog.gr.jp" <i18n@janog.gr.jp>
Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 28 Jun 2014 00:58:12 -0000

On Jun 27, 2014, at 3:27 AM, Shishio Tsuchiya <shtsuchi@cisco.com> wrote:

> Leo and v6ops
> F.Y.I
> JANOG(JApan Network Operator's Group) decided to provide ula address to the JANOG34 conference network.
> http://www.janog.gr.jp/en/index.php?JANOG34_Meeting
> 
> They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along with GUA.
> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02
> 
> If you would like to confirm something on the network , please let me know.

Thanks for this.

I would expect that the key things to prove are the statements in the draft. Also, any observations that might come up would be useful. For example, was it fair to say that the network that was isolated remained isolated? Did using a ULA and a GUA on a globally-accessible network cause any issues? What, if anything, was necessary in the router(s) in question to prevent hosts from using ULA source addresses to connect to GUA addresses? Did hosts in fact form both ULA and GUA-based addresses and use them appropriately when connecting to applications inside and outside the network? 

What one might hope would be that ULA-based addresses were used to connect to other ULA-based addresses, as their bit strings were most similar, and GUA-based addresses were used to connect to other GUA-based addresses, for the same reason. One might hope that ULA prefixes were not announced in BGP without needing extra thought, and that if they were announced, they were not accepted. One might further hope that when a ULA was not announced into a neighboring domain, a packet sent to the ULA prefix didn’t cross the domain boundary.

Of course, we need to hear about any extra work that was required, and any problems that arose. And we need to understand if the deployment of a ULA prefix necessarily implied the deployment of an IPv6/IPv6 NAT or NAPT. I don’t expect that it will and am certainly not asking for it to, but that expectation has been promoted.

JANOG will be Wednesday-Friday the week before IETF 90, and v6ops will meet Monday and Tuesday. It would be nice if someone could make a point of reporting on the experiment.