Subject: Re: (ngtrans) 6to4 issue: link local

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 May 2000 14:53:18 -0500

I'm still struggling with this. 6to4 does exactly what draft-ietf-ngtrans-mech-06.txt
does, by reference. If this problem exists for a 6to4 router, why doesn't it exist for
any IPv6 router connected by a tunnel? In both cases the underlying Interface ID 
on the virtual interface of the router is the IPv4 address. I don't see any difference.

   Brian

[email-masked] wrote:
> 
> >> However, I'm not convinced that the benefits are worth the burden of having an
> >> extra address that will almost never be used.
> >> Could we say that a Link Local is not needed today and if we need it later,
> >> (say for multicast routing to work) we will define it then?
> >If it is needed even once, e.g. for ICMPv6 redirect as itojun suggested,
> >we need to define it.
> 
>         sorry if my analysis was unclear.
>         no, ICMPv6 redirect cannot be used even if you assign link-local
>         onto 6to4 interface.  what we really need is link-local address
>         AND mapping from link-local to IPv4 address.
> 
>         to use ICMPv6, the following conditions must be satisfied:
>         - "gateway" field on routing table needs to be link-local on
>           originating host of the packet (due to validation rules in RFC2461
>           section 8, IIRC)
>         - source address on ICMPv6 packet needs to be link-local of router
> 
>         If you configure the following routing table on the originating host:
> 
> destination     gateway         interface
> default         fe80::x         6to4
> 
>         you'll need to know mapping from fe80::x to IPv4 destination address
>         to send packet via router on fe80::x%6to4 (I love this notation :-)).
>         This is not possible since we do not have mapping between fe80::x
>         to IPv4 address, in 6to4 spec.
> 
>         if we are to use IPv4 address embedded into the last 4 bytes in
>         interface identifier field... hmm, I have never thought about it...
>         we will see two IPv4 address on 6to4 address (2002::/16).
> 
>         I'm not sure if we have real use of ICMPv6 redirect here.
>         on 6to4 cloud, most of the nodes are routers (6to4 relays),
>         not hosts.  routers do not update their routing table on inbound
>         ICMPv6 packets.
> 
>         To summarize:
>         - not sure if ICMPv6 has real use on 6to4 cloud
>         - to use ICMPv6 on 6to4 cloud, we need link-local address AND
>           mapping from link-local to IPv4 address.  ICMPv6 does not work
>           if we don't have the mapping defined.
> 
> itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 01 May 2000 13:42:15 -0700

Hello,

I've not wanted to divert this discussion, but I'd like to point
out that my current personal draft entitled:

 draft-templin-ngtrans-v6v4compat-00.txt

presents an alternate IPv6-IPv4 compatibility address form
that *does* retain the embedded IPv4 address in its link-local
and site-local derivatives. (Some of my research efforts have
entailed using these link and site local derivatives as
source and destination IPv6 addresses for nodes attached to
a common link/site.)

A big disclaimer, however, is that this work is not yet
accepted as 'ngtrans' working group material. I am in the
process of developing a set of generalized sending rules to
show that this address form has application for automatic
IPv6-over-IPv4 tunnel creation, but until these rules are
developed and reviewed this is still just an individual
submission proposal. I believe the addressing architecture
described in my draft has the potential to complement and
augment the existing 6to4 addressing architecture, however.

Fred Templin
[email-masked]

---

From: [email-masked]
Date: Tue, 02 May 2000 08:54:14 +0900

>on the virtual interface of the router is the IPv4 address. I don't see any difference.

	I'm not just talking about link-local address format, but also worried
	about complication due to sending mechanism.

	For other tunnelling mechanisms (like RFC1933 configured tunnel)
	we configure IPv4 address of the peer separately to the router.
	We always know the peer's IPv4 address if we determine outgoing
	interface.

	For 6to4, the only place we can get IPv4 address for a particular
	6to4 desination is from 6to4 prefix (3rd to 6th bytes).  My
	understanding is that we can transmit packets across 6to4 cloud, if
	and only if the destination address (or gateway) belongs to 6to4
	prefix (2002::/16).

itojun