Re: ICMP6 redirect

Hesham Soliman <hesham@elevatemobile.com> Wed, 25 July 2012 11:09 UTC

Return-Path: <hesham@elevatemobile.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A1E21F85AD for <ipv6@ietfa.amsl.com>; Wed, 25 Jul 2012 04:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 w7TjimUE+g0B for <ipv6@ietfa.amsl.com>; Wed, 25 Jul 2012 04:09:32 -0700 (PDT)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8572121F85A3 for <ipv6@ietf.org>; Wed, 25 Jul 2012 04:09:31 -0700 (PDT)
Received: from [60.242.128.199] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1StzSj-0000Hc-Qy; Wed, 25 Jul 2012 21:09:06 +1000
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Wed, 25 Jul 2012 21:08:56 +1000
Subject: Re: ICMP6 redirect
From: Hesham Soliman <hesham@elevatemobile.com>
To: Andrew McGregor <andrewmcgr@gmail.com>
Message-ID: <CC360F42.26C90%hesham@elevatemobile.com>
Thread-Topic: ICMP6 redirect
In-Reply-To: <1DC7DA96-0DF2-4C79-BDEF-0DD038257B41@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-User: hesham@elevatemobile.com
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 25 Jul 2012 11:09:33 -0000

>
>
>
>>>> 
>>>> => The router doesn't need to know the host's route table, it knows
>>>>which
>>>> address it included in its RAs, which is what the host records.
>>>> I'm not sure why you think that there is no way the router can
>>>>construct
>>>> that message reliably. If it uses the same address it uses for its
>>>>RAs,
>>>> it
>>>> can construct the message.
>>> 
>>> Ah.  Well, that will certainly help, but consider a situation where
>>>there
>>> are no RAs, 
>> 
>> => Where is that situation possible/deployed? It's hard to consider
>> something that is against the spec you're commenting on :)
>
>Sure, it is not a situation contemplated by the ND spec.  So, do you mean
>to say it is incorrect configuration for a router to have forwarding on
>and not be sending RAs,

=> This sentence should not imply the following words after "therefore". I
think a router can be forwarding without sending RAs.
But I also think that if you're going to send redirects, you must have
sent an RA. 

> and therefore you should not send redirects if you are not sending RAs?
>That works as a resolution for me, in terms of specs.

=> Yes. I don't think it implies that if you're forwarding you must send
RA's though :). They're two separate issues.
Anyone, that's my opinion given the way the spec is written. It's not
explicitly mentioned in 4861 that you can't send redirects unless you're
also sending RAs, but that seems implicit to me.

>
>However, if it is not a misconfiguration, and you wish to redirect
>traffic that has a better first hop, or is on-link but the host for
>whatever reason does not know that, is that possible?  Should it be?

=> Well, knowing that someone's on-link is based on knowing that the
prefix is on-link. They all seem to be related to information communicated
in the RA. So it makes sense to me to tie this function to a router that
sends RAs. 

>
>I suspect it is a common situation, no matter that it's completely broken.


=> I don't know how common this is honestly. So I'll take your word with
caution. 

Hesham

>
>Andrew