Re: [v6ops] [homenet] Tsinghua work on source/destination routing

神明達哉 <jinmei@wide.ad.jp> Fri, 08 November 2013 07:17 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3F811E8218; Thu, 7 Nov 2013 23:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.222
X-Spam-Level: *
X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX+L4pGE9rdE; Thu, 7 Nov 2013 23:17:38 -0800 (PST)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C3AE221E80E0; Thu, 7 Nov 2013 23:17:36 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id t60so1524537wes.26 for <multiple recipients>; Thu, 07 Nov 2013 23:17:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=GxIZfApjoyV+nJQNbnF4vln2jUUyesbBED7DhS9/xTU=; b=YG/a/a9ZXNxMiQY6bFIDwLtp/Bu1sDJgUs6DVX/Sy5fkxK5iqYP+BtuDvXAG/IIsBU YzlQs8j0GCs/MM98vRMMFokyeu1botPjUsBKmD/XqcUH6h5ZuDG9u0aSJeIh3l3/JmXL kgPzMDzUvmaeDmOFf8sb79Fy6A7OfSGrY2QRvaM7RB5+uKX/fLfXy+ENOGJ/UONt43+N ERa2DVL0OXMnR2m1YrVi7Xzo0V1yqHXhNUbLs9ZUHwEMN+buC0fKSOt4J87o1jf5t/kP hfcZJOIjjHYBX2ucdvON2/lRblHhFKc7+zRF5I6ocepA/y/SfI1wQLlP+re+kLFiUAVM 6w4g==
MIME-Version: 1.0
X-Received: by 10.180.77.19 with SMTP id o19mr1182464wiw.34.1383895055864; Thu, 07 Nov 2013 23:17:35 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Thu, 7 Nov 2013 23:17:35 -0800 (PST)
In-Reply-To: <E06460D8-E347-40F3-A72E-6177C7817CB5@delong.com>
References: <F7C18630-1964-4AFD-8549-559D7582B114@cisco.com> <CAFU7BAQT=+B==8pvOYSsWnCvcMEVzy2nh8dAZZXHzYjwmedRpg@mail.gmail.com> <CAJE_bqfU8C+Tc2rQCZ=vpmfTDdOiGz-sd-G4QNBpHdwXDz9bqQ@mail.gmail.com> <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> <527BE84E.2000205@gmail.com> <CAFU7BATOG_Y4UtpRM9hu1qH7rV8_cxo0XHghrNt0xr5WUZuhiQ@mail.gmail.com> <E06460D8-E347-40F3-A72E-6177C7817CB5@delong.com>
Date: Thu, 07 Nov 2013 23:17:35 -0800
X-Google-Sender-Auth: rHXXLQBy-ng_y7xB_-RYYVzoPgU
Message-ID: <CAJE_bqdiPk=9J8zrh9mds=3wA32GBMdT9w0_4dHcR6Lnsn=CkA@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Owen DeLong <owen@delong.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, Routing WG <rtgwg@ietf.org>
Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 08 Nov 2013 07:17:39 -0000

At Thu, 7 Nov 2013 18:42:02 -0800,
Owen DeLong <owen@delong.com> wrote:

> > I'd note, from purely architectural point of view, that it's totally
> > valid a packet that has a link-local address is forwarded, as long as
> > the packet remains in the originating link zone. [...]
>
> That is not correct…
>
> RFC 4291 says:
[...]
>    Routers must not forward any packets with Link-Local source or
>    destination addresses to other links.
>
> It is quite clear that a packet with a link-local address in either
> field MUST not be forwarded.

Don't forget the "to other links" part.  This make it valid, e.g.,
that a router forwards a packet with a link-local source address back
to the receiving link.  A stubborn person might still argue that
"other" can include the receiving link itself, and in a sense I admit
it might confuse readers.  In fact, such confusion is one of the
things RFC 4007 tried to clarify.  At the very least, I'm 100% sure
this is what Steve (Deering) intended when he co-authored the IPv6
addressing architecture spec and what he tried to clarify in RFC 4007
as a co-author of it.

> >> implementation sounds suspect, and I'm with Jen in wondering why a
> >> router forwarded the packet in the first place.
> >
> > It's not surprising to me since the source address is not needed as
> > long as routing decision is only made based on the destination
> > address.  I noticed one popular router vendor didn't implement this
> > restriction of RFC 4007 correctly many years ago and even reported it
> > to the vendor, but (assuming it's still not fixed) just being "non
> > compliant" is probably not convincing enough for them to introduce
> > additional overhead in their forwarding logic.
>
> It's surprising to me and it means that the router is, by definition, not compliant with RFC 4291, ergo, the router is broken.

Of course it's broken.  But the existence of broken implementations is
not uncommon in general, so simply because something is broken doesn't
mean (to me) it's surprising there's such a thing.  And, in this
particular case, I can even see the incentive of being broken, so it's
not surprising to me at all.  But "surprising" is a subjective concept
anyway, so it's not surprising different people have different sense
of it:-)

--
JINMEI, Tatuya