All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com,
	netdev@oss.sgi.com
Subject: Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT
Date: 17 Jul 2003 17:35:36 +0300	[thread overview]
Message-ID: <1058452536.5781.87.camel@hades> (raw)
In-Reply-To: <Pine.LNX.4.44.0307171648230.6323-100000@netcore.fi>

Pekka,

Looks like I've talked myself around to Alexey's point of view. :-)

On Thu, 2003-07-17 at 16:55, Pekka Savola wrote:
> Note that the spec refers to the generation of your *own* fe80::x address, 
> in the case that e.g. the implementations like to have link-local 
> addresses on interfaces.  One doesn't say that when you're contacting 6to4 
> relays, you should use a link-local address formed like above to 
> communicagte the IP address.

Yes, but section 3.7 of rfc2893 talks about the use of that link-layer
address with routing protocols. I take this to include "as next hop
address".
 
> I disagree a bit on cleanliness.  The problem with the above is that when
> you see the next-hop "fe80::bada:bee4", you can't have any idea whether it
> really means "tunnel to (dec)bada:bee4" or "a router known as
> fe80::bada:bee4".  It depends on the interface.  The context of 6to4 is
> lost.

I would say that is a feature. The next hop address *always* identifies
the next hop router, and it's a link-local unicast as it is supposed to
be. In the case of 6to4, the next hop router just happens to be a 6to4
relay located on the virtual link provided by the SIT interface. The
tunneling is purely a property of the SIT interface, the routing code
doesn't have to care. Theoretically, you could even create solicited
node multicast addresses the same way and run ND over the tunnel (not
that it's needed).

	MikaL

  reply	other threads:[~2003-07-17 14:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030713005345.1fea1092.davem@redhat.com>
2003-07-14 23:29 ` Fw: [PATCH] IPv6: Allow 6to4 routes with SIT kuznet
2003-07-15  6:28   ` Pekka Savola
2003-07-15 14:28     ` kuznet
2003-07-15 19:26       ` Pekka Savola
2003-07-15 23:32         ` kuznet
2003-07-16  6:12           ` Pekka Savola
2003-07-17  0:20             ` kuznet
2003-07-17  7:04               ` Pekka Savola
2003-07-17 11:16                 ` Mika Liljeberg
2003-07-17 11:54                   ` Mika Liljeberg
2003-07-17 13:55                     ` Pekka Savola
2003-07-17 14:35                       ` Mika Liljeberg [this message]
2003-07-16 22:28       ` Mika Liljeberg
2003-07-16 23:28         ` kuznet
2003-07-16 23:39           ` Mika Liljeberg
2003-07-16 23:58             ` kuznet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1058452536.5781.87.camel@hades \
    --to=mika.liljeberg@welho.com \
    --cc=davem@redhat.com \
    --cc=jmorris@redhat.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=netdev@oss.sgi.com \
    --cc=pekkas@netcore.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.