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

Erik Nordmark <> Mon, 14 July 2008 10:42 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id BD10128C25A; Mon, 14 Jul 2008 03:42:34 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DB3D28C25A for <>; Mon, 14 Jul 2008 03:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.857
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Of3j2R-fHO80 for <>; Mon, 14 Jul 2008 03:42:32 -0700 (PDT)
Received: from (sca-ea-mail-2.Sun.COM []) by (Postfix) with ESMTP id 90F8B28C259 for <>; Mon, 14 Jul 2008 03:42:32 -0700 (PDT)
Received: from ([]) by (8.13.7+Sun/8.12.9) with ESMTP id m6EAgwSB018404; Mon, 14 Jul 2008 10:42:58 GMT
Received: from [] (punchin-nordmark.SFBay.Sun.COM []) by (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: <>
Date: Mon, 14 Jul 2008 03:42:48 -0700
From: Erik Nordmark <>
User-Agent: Thunderbird (X11/20070723)
MIME-Version: 1.0
To: Thomas Narten <>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Cc: Brian Haberman <>, Bob Hinden <>,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

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.

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 

Host A sends packet destined to B to the router. Router responds with a 
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.

IETF IPv6 working group mailing list
Administrative Requests: