comments on draft-kohno-ipv6-prefixlen-p2p-00.txt

JINMEI Tatuya / 神明達哉 <jinmei@isc.org> Mon, 09 November 2009 05:36 UTC

Return-Path: <jinmei@isc.org>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2033028C0CF for <ipv6@core3.amsl.com>; Sun, 8 Nov 2009 21:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.05
X-Spam-Level: *
X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz17SOvemgSN for <ipv6@core3.amsl.com>; Sun, 8 Nov 2009 21:36:13 -0800 (PST)
Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by core3.amsl.com (Postfix) with ESMTP id 07F373A69A0 for <ipv6@ietf.org>; Sun, 8 Nov 2009 21:36:13 -0800 (PST)
Received: from jmb.jinmei.org (unknown [IPv6:2001:dfb:0:16:21b:63ff:fe08:3e64]) by mon.jinmei.org (Postfix) with ESMTPA id C4EEF33C3B; Sun, 8 Nov 2009 21:36:36 -0800 (PST)
From: JINMEI Tatuya / 神明達哉 <jinmei@isc.org>
Date: Mon, 09 Nov 2009 14:36:35 +0900
Message-ID: <m2k4y0xnrw.wl%jinmei@isc.org>
To: mkohno@juniper.net, nitzan@juniper.net, randy@psg.com, maz@iij.ad.jp
Subject: comments on draft-kohno-ipv6-prefixlen-p2p-00.txt
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 05:36:14 -0000

(resending as I seem to have submitted the original one from the wrong
address)

I've read this draft.  I don't have a strong opinion on the proposal
per se, but have a couple of minor comments:

1. In Section 4, the draft says:

   However, Subnet-router
   anycast address has not been implemented and in practice, this has
   not been a problem.

I'm afraid "has not been implemented" is too strong.  In fact, we have
"implemented" it in the KAME/BSD IPv6 stack in that we implemented
special restrictions (at that time) on anycast addresses and had
experimentally assigned subnet-router anycast addresses on PC-based
IPv6 routers.  In general, it's difficult to declare something hasn't
been implemented because it eliminates any minor implementation
activity, which is almost impossible to prove.

I have no objection to the conclusion itself (i.e. not a problem in
practice) and would rephrase it to something like this:

   However, Subnet-router anycast addresses have not been (widely)
   deployed, and this has not been a problem in practice.

2. In section 5, it states:

         1) A rule described in ICMPv6 [RFC4443] indicates that a
         Destination Unreachable (Code 3) message should be sent by a
         router rather than forwarding packets back onto point-to-point
         links from which they were received if their destination
         address belongs to the link itself.

This sentence is clear, but IMO is not perfectly accurate because an
address doesn't belong t(or isn't assigned to) a *link*; it's assigned
to an interface.  The corresponding text of RFC4443 reads:

   One specific case in which a Destination Unreachable message is sent
   with a code 3 is in response to a packet received by a router from a
   point-to-point link, destined to an address within a subnet assigned
   to that same link (other than one of the receiving router's own
   addresses).

where it's a *subnet* that is assigned to the link.  So, to be very
accurate, I'd propose to revise the text (e.g.) as follows:

         1) A rule described in ICMPv6 [RFC4443] indicates [...]
         if their destination address matches a subnet that belongs to
         the link itself.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.