Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Erik Nordmark <erik.nordmark@sun.com> Mon, 14 July 2008 10:42 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD10128C25A; Mon, 14 Jul 2008 03:42:34 -0700 (PDT)
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 6DB3D28C25A for <ipv6@core3.amsl.com>; Mon, 14 Jul 2008 03:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.857
X-Spam-Level:
X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1]
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 Of3j2R-fHO80 for <ipv6@core3.amsl.com>; Mon, 14 Jul 2008 03:42:32 -0700 (PDT)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 90F8B28C259 for <ipv6@ietf.org>; Mon, 14 Jul 2008 03:42:32 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.108.31]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6EAgwSB018404; Mon, 14 Jul 2008 10:42:58 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6EAgrsO747476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 03:42:56 -0700 (PDT)
Message-ID: <487B2DA8.2030709@sun.com>
Date: Mon, 14 Jul 2008 03:42:48 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
References: <486388BD.2090801@innovationslab.net> <200807031925.m63JPRp7031611@cichlid.raleigh.ibm.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EB6@xmb-rtp-20e.amer.cisco.com> <200807032111.m63LBUCF014613@cichlid.raleigh.ibm.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EB9@xmb-rtp-20e.amer.cisco.com> <m2k5fv6b4b.wl%Jinmei_Tatuya@isc.org> <200807100143.m6A1h0sG026605@cichlid.raleigh.ibm.com>
In-Reply-To: <200807100143.m6A1h0sG026605@cichlid.raleigh.ibm.com>
Cc: Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@nokia.com>, 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: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Thomas Narten wrote:

> When NodeA issues a NS for NodeB, that usually means that NodeA has
> traffic to send to NodeB, and NodeB will shortly thereafter send a
> response packet back to/through NodeA. In IPv4, that requires both
> sides issue ARPs independently. I.e., NodeA has to ARP for NodeB, and
> NodeB then later has to ARP for NodeA. A total of 4 packets, 2 of them
> broadcast.
 >
> With ND, we can short circuit the need for the second packet
> exchange. When NodeA issues an NS for NodeB, NodeB (per the rule we
> have been discussing) goes ahead and creates a Neighbor Cache Entry
> for NodeA (i.e., from the source address of the NS). When NodeB then
> generates a response packet, it doesn't need to do an additional NS/NA
> exchange, because it already has an entry for the desired address.

FWIW RFC 826 specifies exactly the same thing - learn from the source 
protocol address and hardware address so that only 2 ARP packets are needed.

The case where bullet three and four would potentially help is when 
there is a NMBA network and as a result no on-link prefixes, or when 
different nodes are configured with different on-link prefixes.

Let's look at those in turn.
NBMA:
-----

Host A and Host B have an empty on-link prefix list hence all packets 
are initially sent to a default router. The default routers are assumed 
to know (through magic) all the IP and L2 addresses of the nodes on the 
link.

Host A sends packet destined to B to the router. Router responds with a 
redirect.
When host B responds to A that packet also goes to the router and 
results in a redirect.
That results in both host A and host B knowing that they are on-link 
with no use of NA or NS, and no use of bullet 3 and bullet 4.

Differently configured hosts:
-----------------------------

Host A and host B are on the same link.
Host A has been configured with IP address P1:A and with on-link 
prefixes P1 and P2.
Host B has been configured with IP address P2:B and on-link prefix P2.
(Note that this requires manual configuration since RFC 4861/4862 can't 
create such a configuration.)

When A sends a packet to P2:B it will multicast a NS since it views P2 
as on-link.
Taking bullet 4 into account B will treat P1:A as on-link, thus a single 
NS/NA exchange is sufficient.

If we remove bullet 4 then B would respond by sending the packet to a 
default router. Presumably that router knows P1 is on-link (so it can 
forward the packet back out the link) hence it would send a redirect 
back to B telling B that P1:A is on-link.

Thus in the case of statically inconsistently configured hosts we do 
same 2 packets sent on the wire as a result of bullet 4.


I can't come up with a case where bullet 3 would make a difference.

    Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------