Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[kuznet]

Hello!

> Hey guys, even though yoshfuji is away I don't see any
> reason why I shouldn't apply the patch below to both
> 2.4.x and 2.5.x.  It looks very uncontroversial to me.
> 
> Any objections?

I would wait for experts.

Technically IPv6 does not allow use of non-link-local address
as nexthop address, because nexthop address is expected to be unique
for router.

Use of IPv4-COMPAT format for tunnels was a hack to make use of tunnel more
handly, it just a tricky way to encapsulate an IPv4 address inside
IPv6 one, it has nothing to do with _real_ IPv4-COMPAT addresses,
(though logically IPv4-COMPAT addresses _are_ really link-local
for 6over4 "network") it is just an element of our API. Use of 6of4 address
is very strange idea in this context, it does not contradict to anything,
of course, but it looks utterly stupid: 6to4 is a complicated format, where
information about nexthop is encoded in an inapproriate way.
The questions sort of: "What the hell? I do a route with nexthop
2002:x:y::a:b and a:b disappears somewhere." And the question is right,
because plain logic requires to use a:b as meaningful part of nexthop,
it is the part which provides node _identity_, x:y is just routing information,
identifying particullar "6to4" network, it is meaningless when used
as a nexthop address.

Shortly, this is mess. Technically, it is just one more trick and useless one,
logically... mess.

Alexey

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Pekka Savola]

On Tue, 15 Jul 2003 kuznet@ms2.inr.ac.ru wrote:
> > Hey guys, even though yoshfuji is away I don't see any
> > reason why I shouldn't apply the patch below to both
> > 2.4.x and 2.5.x.  It looks very uncontroversial to me.
> > 
> > Any objections?
> 
> I would wait for experts.
> 
> Technically IPv6 does not allow use of non-link-local address
> as nexthop address, because nexthop address is expected to be unique
> for router.

I think we have two choices here:

 1) modify /sbin/ip and /sbin/route (and the rest if any) so that they'll
parse global next-hop information and resolve it for the kernel, and
report the resolved information to the kernel (see the other thread)

 2) the kernel supports "must-resolve" next-hops.

> Use of IPv4-COMPAT format for tunnels was a hack to make use of tunnel more
> handly, it just a tricky way to encapsulate an IPv4 address inside
> IPv6 one, it has nothing to do with _real_ IPv4-COMPAT addresses,
> (though logically IPv4-COMPAT addresses _are_ really link-local
> for 6over4 "network") it is just an element of our API. Use of 6of4 address
> is very strange idea in this context, it does not contradict to anything,
> of course, but it looks utterly stupid: 6to4 is a complicated format, where
> information about nexthop is encoded in an inapproriate way.
> The questions sort of: "What the hell? I do a route with nexthop
> 2002:x:y::a:b and a:b disappears somewhere." And the question is right,
> because plain logic requires to use a:b as meaningful part of nexthop,
> it is the part which provides node _identity_, x:y is just routing information,
> identifying particullar "6to4" network, it is meaningless when used
> as a nexthop address.

Apart from architectural purity (I agree it's messy), I think the
practical situation is rather simple: for the case of a:b in 6to4, they're
always irrelevant.  They always refer to the same next-hop whatever
information you'll put in there, the implementations won't care (because
as a next-hop, it's just a way of saying "the router at address
2002:V4ADDR".

Note that nothing _prevents_ you from treating a:b in 2002:x:y::a:b as a
meaningful part of the nexthop.  They'll just always refer to the same
node for whatever a:b you use.  Note that the prefix length of
2002:x:y::a:b is /16 -- you should really rewrite your next-hop
considerations with s/a:b/x:y::a:b/.

I think the problem for of implementation is that "6to4" technique has
just been hacked in (but quite nicely).  It's a bit, but not much, more
special than that IMO.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[kuznet]

Hello!

>  1) modify /sbin/ip and /sbin/route (and the rest if any) so that they'll
> parse global next-hop information and resolve it for the kernel, and
> report the resolved information to the kernel (see the other thread)

No, really. It is problem of user to supply reasonable values.
This policy is not forced, because there are many cases when it does not
make sense (f.e. on all the routers, on all the PtP interfaces et al).

Verification of validity of nexthop is to be done only when receiving
nexthop through addrconf or redirect et al. I guess interiour protocols
also should take care of it.


>  2) the kernel supports "must-resolve" next-hops.

I do not know what it is.


> practical situation is rather simple: for the case of a:b in 6to4, they're
> always irrelevant.

Sure. It is becasue use of 6to4 address is meaningless in this context.
It is thought which I try to deliver.


> Note that nothing _prevents_ you from treating a:b in 2002:x:y::a:b

I do not understand the rest.

Listen, tunnel needs an _IPv4_ address for destiantion of tunnel.
Because our routing does not permit to use different address family
as nexthop, we did trick presenting it as an IPv4-compat address.
We could do this differently, f.e. to use FFFF:EEEE:IPv4-addr:CCCC:DDDD
with the same success or any other randomly chosen encapsulation.

And this silly combination is still _better_ than 6to4 address, which
contains redundant information, which can be mixed up with real _IPv6_
6to4 addresses and whihc contains IPv4 address in some place which
used to be identification of a network prefix.



Alexey

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Pekka Savola]

On Tue, 15 Jul 2003 kuznet@ms2.inr.ac.ru wrote:
> >  1) modify /sbin/ip and /sbin/route (and the rest if any) so that they'll
> > parse global next-hop information and resolve it for the kernel, and
> > report the resolved information to the kernel (see the other thread)
> 
> No, really. It is problem of user to supply reasonable values.

Such addresses are link-locals, of link local scope only.  A link-local 
IPv6 address is awfully difficult to remember and type for all of your 
possible links.

The only reasonable value user could supply is a global address.  If the 
user doesn't have to supply anything .. that's another thing.

> Listen, tunnel needs an _IPv4_ address for destiantion of tunnel.
> Because our routing does not permit to use different address family
> as nexthop, we did trick presenting it as an IPv4-compat address.
> We could do this differently, f.e. to use FFFF:EEEE:IPv4-addr:CCCC:DDDD
> with the same success or any other randomly chosen encapsulation.
> 
> And this silly combination is still _better_ than 6to4 address, which
> contains redundant information, which can be mixed up with real _IPv6_
> 6to4 addresses and whihc contains IPv4 address in some place which
> used to be identification of a network prefix.

Note that what is redundant information in certain scenarios for the
*kernel* may not be redundant information for the *user*.

Please describe what you mean by "real IPv6 6to4 addresses".

If the node processing those as a next-hop supports 6to4 and has the sit0
pseudointerface configured, the address will be but through the special
handling.

If the node doesn't support 6to4 or doesn't have the sit0 pseudointerface 
configured, the address will be processed as normal, as any other IPv6 
nexthop.

Right?

I fail to see what's the fuss about redundant information.  

Redundant information can be ignored.  This is not computer science
theory, removing everything which is not directly relevant.  The use of
the same representation for the next-hop (2002:F00:BA::x) as an address
(2002:BA:F00:y) is the only logical, user-friendly way.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[kuznet]

Hello!

> Such addresses are link-locals, of link local scope only.  A link-local 
> IPv6 address is awfully difficult to remember and type for all of your 
> possible links.
> 
> The only reasonable value user could supply is a global address.

So what? I do not see connection to previous. You want to live with global
addresses as nexthop? OK. But I remember you have spoken something quite
opposite yesterday.


> Please describe what you mean by "real IPv6 6to4 addresses".
...
> If the node processing those as a next-hop supports 6to4 and has the sit0
> pseudointerface configured, the address will be but through the special
> handling.
> 
> If the node doesn't support 6to4 or doesn't have the sit0 pseudointerface 
> configured, the address will be processed as normal, as any other IPv6 
> nexthop.
> 
> Right?

I do not understand why did you ask previous question. You answered to
this.


> Redundant information can be ignored.  This is not computer science
> theory, removing everything which is not directly relevant.  The use of
> the same representation for the next-hop (2002:F00:BA::x) as an address
> (2002:BA:F00:y) is the only logical, user-friendly way.

What a bullshit... The second is address of host "x". The first is supposed
to be address of host F00:BA, whatever it is. Probably, you can decrypt
this only because poisoned by computer science. :-)

Just to complete discussion, let's stay on format fe80::A.B.C.D, for example.
Unlike anothers it is 100% logically clean. :-)

Alexey

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Pekka Savola]

On Wed, 16 Jul 2003 kuznet@ms2.inr.ac.ru wrote:
> > Such addresses are link-locals, of link local scope only.  A link-local 
> > IPv6 address is awfully difficult to remember and type for all of your 
> > possible links.
> > 
> > The only reasonable value user could supply is a global address.
> 
> So what? I do not see connection to previous. You want to live with global
> addresses as nexthop? 

Yes, I dare to say that they're a requirement. 

(But to be clear, when I talk about "global nexthop", I'm only interested 
in nexthops which are on-link.  That is, if you have prefix 
3FFF:FFFF:A:B::/64, setting 3FFE:FFFF:A:B::1 would be ok, but 
3FFE:FFFF:F00:BA::1 would not *have* to work.) 

> OK. But I remember you have spoken something quite
> opposite yesterday.

I don't recall that.  I think I was only suggesting that ONE possible way 
of implementing it (which I wouldn't think is the best one) is make that 
the user space tools' problem: i.e. make them resolve a globally addressed 
nexthop to a link-local nexthop.
 
> > Redundant information can be ignored.  This is not computer science
> > theory, removing everything which is not directly relevant.  The use of
> > the same representation for the next-hop (2002:F00:BA::x) as an address
> > (2002:BA:F00:y) is the only logical, user-friendly way.
> 
> What a bullshit... The second is address of host "x". The first is supposed
> to be address of host F00:BA, whatever it is. Probably, you can decrypt
> this only because poisoned by computer science. :-)

You read too much to in what I wrote (or maybe I wrote too much :-) -- 
what I mean is that 6to4 addresses have a very specific format.  It's 
completely illogical and unfriendly to the users to require use different 
formats when they use 6to4 addresses as nexthops and "normal" addresses.
 
> Just to complete discussion, let's stay on format fe80::A.B.C.D, for example.
> Unlike anothers it is 100% logically clean. :-)

I can't disagree with you there; it's simple, but it's NOT what 
specifications use and the *users* want and need to use.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[kuznet]

Hello!

> Yes, I dare to say that they're a requirement. 

Nope. IPv6 host routing is based on assumption of link-locality
of the next hop. Probably, you want to read some rfcs or to look into code.

> the user space tools' problem: i.e. make them resolve a globally addressed 
> nexthop to a link-local nexthop.

Impossible, as I said.

[ NOTE, the subject changed back to correct one at this point. Seems,
  one sentence, written by me has grown to some huge tumor eating
  original one completely. :-) ]


> specifications use and the *users* want and need to use.

Sigh, there no specifications about tricks used by Linux routing tables,
*users* are unlikely to want to use this feature at all, as Mika noticed.
And when they want, they want to right:

    ip route add 3ffe::.... via 193.233.7.65

rather than crap sort of

    ip route add 3ffe::.... via 2002:<something in latin>

I do not understand, what the hell is going on with you.
I am already sorry that started this. :-)

Alexey

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Pekka Savola]

On Thu, 17 Jul 2003 kuznet@ms2.inr.ac.ru wrote:
> > Yes, I dare to say that they're a requirement. 
> 
> Nope. IPv6 host routing is based on assumption of link-locality of the
> next hop. Probably, you want to read some rfcs or to look into code.

This is not correct.  Perhaps the RFC's have changed in the meantime, but 
at least RFC2461 does *not* make such an assumption (AFAICS).

In the document, there is a basic assumption that the next-hop is
*on-link*.

In the document, there are assumptions on verifying whether the redirects
come from the router you're currently using: this is simpler when you 
use only link-locals as next-hops, but it is certainly *NOT* a 
requirement.

(The spec in question will be revised in the short term, so I'll take this
issue up for clarification..)

> > specifications use and the *users* want and need to use.
> 
> Sigh, there no specifications about tricks used by Linux routing tables,
> *users* are unlikely to want to use this feature at all, as Mika noticed.
> And when they want, they want to right:
> 
>     ip route add 3ffe::.... via 193.233.7.65

That would be simpler but, we actually require:

ip route add 3ffe::... via ::193.233.7.65

and thus require a route for ::/96.  That's confusing: ::/96 has a very 
specific purpose in RFCs, and we should not be overloading the 
functionality, it's just plain confusing.
 
> rather than crap sort of
>
>     ip route add 3ffe::.... via 2002:<something in latin>

I'm not saying we need to prevent the users from using the former.  I'm 
just saying that we must not prevent the users from using the latter; 
please check e.g. the RFC3068 section 2.5.  If we don't support something 
like that, it'll just confuse the users more.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Mika Liljeberg]

On Thu, 2003-07-17 at 10:04, Pekka Savola wrote:
> >     ip route add 3ffe::.... via 193.233.7.65
> 
> That would be simpler but, we actually require:
> 
> ip route add 3ffe::... via ::193.233.7.65
> 
> and thus require a route for ::/96.  That's confusing: ::/96 has a very 
> specific purpose in RFCs, and we should not be overloading the 
> functionality, it's just plain confusing.

I agree with Pekka. Alexey, you yourself admitted that this hack was put
in, because you needed a way to represent an IPv4 address in IPv6
format. The IPv4-mapped format (::ffff:a.b.c.d) exists exactly for this
purpose. User space tools can accept it as a.b.c.d and convert to
IPv4-Mapped for the IPv6 API. There is no need to invent non-standard
practises.

It may be convenient to think that the IPv4 Internet is a virtual link
connecting all 6to4 routers and IPv4 compatible addresses could be seen
as the link-local addresses, but this is just an affectation that is not
backed by any IETF specification. Overloading the IPv4-compatible
address in this way is just confusing, because it creates the impression
that the stack will actually take steps to resolve the gateway address
to a next hop address that is on-link. (I'm not saying it should, but
you can see where the confusion arises).

	MikaL

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Mika Liljeberg]

On Thu, 2003-07-17 at 14:16, Mika Liljeberg wrote:
> On Thu, 2003-07-17 at 10:04, Pekka Savola wrote:
> > >     ip route add 3ffe::.... via 193.233.7.65
> > 
> > That would be simpler but, we actually require:
> > 
> > ip route add 3ffe::... via ::193.233.7.65
> > 
> > and thus require a route for ::/96.  That's confusing: ::/96 has a very 
> > specific purpose in RFCs, and we should not be overloading the 
> > functionality, it's just plain confusing.
> 
> I agree with Pekka. Alexey, you yourself admitted that this hack was put
> in, because you needed a way to represent an IPv4 address in IPv6
> format. The IPv4-mapped format (::ffff:a.b.c.d) exists exactly for this
> purpose. User space tools can accept it as a.b.c.d and convert to
> IPv4-Mapped for the IPv6 API. There is no need to invent non-standard
> practises.

Ok, I have to correct myself a bit here. Looking at the 6to4 RFC it
actually does recommend the fe80::v4addr format, already mentioned, in
case a link-local address is needed.

So we would have:

ip route add 3ffe:... via fe80::bada:bee4 dev sitX

Clean, although not as convenient for the user.

	MikaL

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Pekka Savola]

On 17 Jul 2003, Mika Liljeberg wrote:
> On Thu, 2003-07-17 at 14:16, Mika Liljeberg wrote:
> > On Thu, 2003-07-17 at 10:04, Pekka Savola wrote:
> > > >     ip route add 3ffe::.... via 193.233.7.65
> > > 
> > > That would be simpler but, we actually require:
> > > 
> > > ip route add 3ffe::... via ::193.233.7.65
> > > 
> > > and thus require a route for ::/96.  That's confusing: ::/96 has a very 
> > > specific purpose in RFCs, and we should not be overloading the 
> > > functionality, it's just plain confusing.
> > 
> > I agree with Pekka. Alexey, you yourself admitted that this hack was put
> > in, because you needed a way to represent an IPv4 address in IPv6
> > format. The IPv4-mapped format (::ffff:a.b.c.d) exists exactly for this
> > purpose. User space tools can accept it as a.b.c.d and convert to
> > IPv4-Mapped for the IPv6 API. There is no need to invent non-standard
> > practises.
> 
> Ok, I have to correct myself a bit here. Looking at the 6to4 RFC it
> actually does recommend the fe80::v4addr format, already mentioned, in
> case a link-local address is needed.

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.
 
> So we would have:
> 
> ip route add 3ffe:... via fe80::bada:bee4 dev sitX
> 
> Clean, although not as convenient for the user.

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.

For that reason, IMO 2002:v4:addr is the clearest, and "via v4addr" seems
like the next best one (IMHO).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Mika Liljeberg]

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

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Mika Liljeberg]

Alexey,

> And this silly combination is still _better_ than 6to4 address, which
> contains redundant information, which can be mixed up with real _IPv6_
> 6to4 addresses and whihc contains IPv4 address in some place which
> used to be identification of a network prefix.

While I see where you're coming from, I don't really understand what the
fuss is all about.

IMHO, the real hack is being able to specify the tunnel endpoint using a
gateway route in the first place. Whether that gateway address is
IPv4-compatible or a 6to4 address is just a minor detail. I view my
patch as a simple convenience to the user, extending a hack that already
exists.

A more "correct" way would be to specify the gateway address in the
remote address field of the point-to-point SIT interface, and live with
the fact that you need a separate SIT interface for each 6to4 gateway
that you want to tunnel to. This already works, so the IPv4-compat route
hack is actually redundant. My understanding was that it is there simply
for convenience.

	MikaL

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[kuznet]

Hello!

> While I see where you're coming from, I don't really understand what the
> fuss is all about.

The issue definitely does not worth of time already spent for the discussion.

All the fuss is about the fact that this code lived and will live for years.
If we allowed to add small tricks of this kind, it would end up as a full mess.
Each convenience trick must have a logical background.

I have been asked for an opinion, this is my opinion: 6to4 is wrong,
addresses in format of 6over4 are natural, if they are deprecated,
another and even more natural variant is use of link-local format,
fe80::a.b.c.d.

Alexey

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[Mika Liljeberg]

On Thu, 2003-07-17 at 02:28, kuznet@ms2.inr.ac.ru wrote:
> > While I see where you're coming from, I don't really understand what the
> > fuss is all about.
> 
> The issue definitely does not worth of time already spent for the discussion.

I agree. :)

> All the fuss is about the fact that this code lived and will live for years.
> If we allowed to add small tricks of this kind, it would end up as a full mess.
> Each convenience trick must have a logical background.

So what's the background for having the hack to specify a tunnel EP with
a gateway route?

> I have been asked for an opinion, this is my opinion: 6to4 is wrong,
> addresses in format of 6over4 are natural, if they are deprecated,
> another and even more natural variant is use of link-local format,
> fe80::a.b.c.d.

IPv4-mapped would be semantically correct. It definately can't be
confused with any real IPv6 address.

	MikaL

Re: Fw: [PATCH] IPv6: Allow 6to4 routes with SIT

[kuznet]

Hello!

> So what's the background for having the hack to specify a tunnel EP with
> a gateway route?

Technically, it allows to avoid creating hundreds of devices to maintain lots
of tunnels.

Actually, it exists due to historical reasons. ipip and ipip6
tunnels used the trick from the very beginning.

But f.e. ipgre device was new, so it uses more correct approach:
actual mapping cross address families can be made via neighbour tables.
But this requires to know an IPv6 address of the nexthop.
Clean, but inconvenient. :-)

Alexey