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

"Hemant Singh (shemant)" <shemant@cisco.com> Mon, 30 June 2008 14:37 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 4638C3A681E; Mon, 30 Jun 2008 07:37:43 -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 AE2E83A63EC for <ipv6@core3.amsl.com>; Mon, 30 Jun 2008 07:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Lm6CJ5MiScrq for <ipv6@core3.amsl.com>; Mon, 30 Jun 2008 07:37:40 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2409D3A6AB7 for <ipv6@ietf.org>; Mon, 30 Jun 2008 07:36:47 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,727,1204520400"; d="scan'208";a="12693380"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2008 10:36:58 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5UEawtd007444; Mon, 30 Jun 2008 10:36:58 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5UEawr0004416; Mon, 30 Jun 2008 14:36:58 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 10:36:45 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Date: Mon, 30 Jun 2008 10:36:45 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41E2B@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D0170C2BD@SGSINSMBS02.ad4.ad.alcatel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjXjoFxMisnTMw3QlKNp3HTw669XgAAhZKAAAHjtdAAFQYzcACyUa8g
References: <D9872168DBD43A41BD71FFC4713274D405429068@xmb-ams-33b.emea.cisco.com><BB56240F3A190F469C52A57138047A03A2C459@xmb-rtp-211.amer.cisco.com> <986DCE2E44129444B6435ABE8C9E424D0170C2BD@SGSINSMBS02.ad4.ad.alcatel.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "MILES DAVID" <David.Miles@alcatel-lucent.com.au>, "Wes Beebee (wbeebee)" <wbeebee@cisco.com>, "Wojciech Dec (wdec)" <wdec@cisco.com>, "Brian Haberman" <brian@innovationslab.net>, <ipv6@ietf.org>
X-OriginalArrivalTime: 30 Jun 2008 14:36:45.0584 (UTC) FILETIME=[B89A9900:01C8DABE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7830; t=1214836618; x=1215700618; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco. com> |Subject:=20RE=3A=206MAN=20WG=20Last=20Call=3Adraft-ietf-6m an-ipv6-subnet-model-00.txt |Sender:=20 |To:=20=22MILES=20DAVID=22=20<David.Miles@alcatel-lucent.co m.au>,=0A=20=20=20=20=20=20=20=20=22Wes=20Beebee=20(wbeebee) =22=20<wbeebee@cisco.com>,=0A=20=20=20=20=20=20=20=20=22Wojc iech=20Dec=20(wdec)=22=20<wdec@cisco.com>,=0A=20=20=20=20=20 =20=20=20=22Brian=20Haberman=22=20<brian@innovationslab.net> ,=20<ipv6@ietf.org>; bh=2lKFzAIPNDhg1zdyxnldktCg7AsuJqTo3xeKMKkBFP0=; b=UisO1KBXfRLo/scUNBjZS3NsBZBGUrFyGlRV8C3u+BJsu5wlGJpS7HuZDs b8WabrizHeA10KrzmeShTUxkMKJ5PNowONurdIpZ1ABB+Ocmlz87NiuNjofy yS0qLOlvqX;
Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: Bob Hinden <bob.hinden@nokia.com>
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

David,

We will explain where we think RFC4861 came from with the 4th bullet in
on-link definition in Terminology section of RFC4861. We will explain
why that bullet is needed and why the bullet does not change. Further,
we don't understand where you are going with these contrived examples?
It's a stretch already being in a router-less network and contriving
examples that clearly have source-address selection problems. In the
routerA to routerB contrived example, the example included routes
between A and B. We have said routing table takes precedence over ND
cache in that example. For the host to host case below, since IPv6
addresses have been configured on the hosts with a prefix length, each
host has an entry in data forwarding table for the prefix derived from
host IPv6 address configuration. IPv6 data forwarding tables on the host
will take precedence in the same way as in your router example.

Anyhow, here is the justification for the 4th bullet in RFC 4861 which
is what statements in our draft derive from.

In a router-less network, a node's network interface may be configured
using manual configuration or DHCPv6. Note DHCPv6 does not dole out
prefix length without which, just given an IPv6 address from DHCPv6, a
DHCPv6 client cannot make an on-link determination for any prefix.
Likewise, manual configuration may not configure a prefix length when an
IPv6 address is configured on the interface - in this case, the node
still does not have any means to determine what prefix is on-link.  Thus
far, any host in this network has not been able to determine if any
prefix is on-link. Only if the host is able to determine any prefix is
on-link, can the host in such a network send data. There in comes the
rule in 4th bullet from the definition of on-link from RFC4861 that
applies to this network

- any Neighbor Discovery message is received from the address.

Hemant & Wes

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
MILES DAVID
Sent: Thursday, June 26, 2008 8:57 PM
To: Wes Beebee (wbeebee); Wojciech Dec (wdec); Brian Haberman;
ipv6@ietf.org
Cc: Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Wes & Hemant,

Can we walk through the situation of hosts without routers where you
suggest a possible issue?


HostA ----(link)---- HostB

HostA:
2002:db8:100::1234/64
2002:db8:200::1234/64

HostB:
2002:db8:100::9999/64

Are we suggesting HostA may src from 2002:db8:200::1234 to
2002:db8:100::9999, ie, we are forgoing source-address selection and are
overriding this behaviour?
Assuming that is the case, and assuming HostB did in fact populate a
Neighbour Cache entry with 2002:db8:200::1234 - STALE, I cannot see how
this would affect HostB's next-hop/on-link determination.

According to the current text in RFC4861 HostB would perform the
following on the first packet to send to 2002:db8:200::1234:
1) Check destination cache (empty, never seen this destination before)
2) Check Prefix List for on-link determination (off-link) -
2002:db8:200::1234 is not in the Prefix List
3) If off-link, select a router from Default Router List and determine
next-hop IP (no default routers) --end in our example as there are no
routers--
4) Consult Neighbour Cache for link-layer address of next-hop, invoke
Address Resolution if needed
5) Cache result in destination cache

I understand Neighbour Cache is not consulted for next-hop/on-link
determination, and Destination Cache is updated with the result of the
Prefix-List lookup (next-hop determination). So while there is a STALE
entry in the Neighbour Cache, it is never queried. Similar to the case
of a router, I think we would need to update a host's equivalent (the
Prefix List) to affect forwarding.

It would be good to better understand the scenario you are seeing
between host and host. 


Best Regards,

-David



-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:wbeebee@cisco.com]
Sent: Friday, 27 June 2008 12:29 AM
To: Wojciech Dec (wdec); Brian Haberman; ipv6@ietf.org
Cc: MILES DAVID; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

This rule derives directly from the Terminology section of RFC 4861
(definition of on-link).

Note that the presence of a bogus entry causes no harm (the routing
table takes precedence over the ND cache in this case).

However, the removal of the rule DOES cause harm in the case of
communication without routers.

Therefore, we currently see no reason to change the text.

- Wes & Hemant

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Wojciech Dec (wdec)
Sent: Thursday, June 26, 2008 10:05 AM
To: Brian Haberman; ipv6@ietf.org
Cc: MILES DAVID; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Based on a recent thread
(http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00896.html) the
following paragraph from the draft appears to warrant some more thought
if not outright a revision

"   In addition to the Prefix List, individual addresses are on-link if
   they are the target of a Redirect Message indicating on-link, or the
   source of a valid Neighbor Solicitation or Neighbor Advertisement
   message.  Note that Redirect Messages can also indicate an address is
   off-link.  Individual address entries can be expired by the Neighbor
   Unreachability Detection mechanism."

Using unconditionally the source address of a neighbour solicitation or
NA to determine on-link would indeed appear to be undesirable, unless
the intent is allow some direct host-host cross subnet/prefix
communication without a router involved at any stage (this is not a good
idea IMO). A constraint could be introduced such as: A host only learns
on-link addresses from the source of NS and NA messages iff it already
has an on-link prefix that would cover that address. Learning from
Redirect messages would continue to be allowed.

My 2c.
-Woj.
 

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf 
> Of Brian Haberman
> Sent: 26 June 2008 14:17
> To: ipv6@ietf.org
> Cc: Bob Hinden
> Subject: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
> 
> All,
>       This message starts a 3-week 6MAN Working Group Last Call on
> advancing:
> 
>       Title     : IPv6 Subnet Model: the Relationship between
>                   Links and Subnet Prefixes
>       Author(s) : H. Singh, et al.
>       Filename  : draft-ietf-6man-ipv6-subnet-model-00.txt
>       Pages     : 8
>       Date      : 2008-05-08
> 
> as a Proposed Standard.  Substantive comments and statements of 
> support for advancing this document should be directed to the mailing 
> list.
> Editorial suggestions can be sent to the document editor.  
> This last call will end on July 10, 2008.
> 
> Regards,
> Brian & Bob
> 6MAN co-chairs
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------