On Tue, 11 Dec 2001, Tony Hain wrote:
> Pekka Savola wrote:
> > New addrarch draft says ff0e::/16 is global-scope.
> Where? What I see on page 16 is:
> Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0
> ...
> FF0E:0:0:0:0:0:0:0
> FF0F:0:0:0:0:0:0:0
>
> The above multicast addresses are reserved and shall never be
> assigned to any multicast group.
draft-ietf-ipngwg-addr-arch-v3-07.txt
2.7 Multicast Addresses
[...]
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group. The values are:
[...]
E global scope
> > I took this as an example of delivering packets to an IPv6
> > node when it
> > might not be possible to do so directly (example: link-local
> > addresses).
>
> I am not seeing your scenario. Could you send a picture?
Consider Target Node T has two interfaces with two addresses,
respectively: 2002:0102:0304::1 and 3ffe:ffff:1::1. The first one is
"public" and the second is "private". 3ffe:ffff:1::/64 is not routed
except locally.
Target node T has not enabled packet forwarding between interfaces, or it
is being strictly limited by firewall policies.
If Attacker A pings 2002:0102:0304::1 it works no problems. If attacker
pings 3ffe:ffff:1::1, there is no reply as the network is not reachable to
the Internet on purpose.
Now, attacker A can craft a packet as follows:
ipv4 source=<something>
ipv4 destination=1.2.3.4
protocol=41
ipv6 source=<something>
ipv6 destination=3ffe:ffff:1::1
[payload follows]
Target node T decapsulated the IPv4 packet and delivers the IPv6 packet to
3ffe:ffff:1::1 without complaints. This would not have been possible
without automatic tunneling mechanisms.
This issue is similar to "Routing Header" discussion in:
http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt
> > Why would a host have any reason to be 6to4 aware? I sure
> > would like to
> > know more of this. AFAICS that implementation wouldn't be
> > honouring RFC
> > 3056 definition of 6to4 host:
> >
> > an IPv6 host which happens to have at least one 6to4 address.
> > In all other respects it is a standard IPv6 host.
>
> The RFC 3056 context of a 6to4 host is one that receives an RA which
> contains a 6to4 format prefix. It is also possible that the host has no
> IPv6 router, but includes that function within itself. In the strict
> sense the functions are separate, but the fact that they are in the same
> box results in the case where a 6to4 host may have a 6to4
> pseudo-interface.
I wonder why this definition was chosen. But regardless, the discussion
applies, just imagine "6to4 host" being "6to4 host which is not 6to4
router".
> > That is, site-local and link-locals
> > would not be a
> > problem with tunneling.
>
> Link local is not to be forwarded off link in any case, and I have
> always believed that site-locals don't go out over the global tunnel
> interface, but there doesn't appear to be a specific statement about
> that in the current documents.
Addrarch 2.5.8 says site-locals must not be forwarded outside of site, and
upon receipt, should be dropped.
A problem is that one does not know how tunneling is implemented. If one
receives a packet from a tunnel, does one apply all the same checks one
would if the packet had come from the wire? Or does the implementation
somehow push the packet through in some quicker way?
Site/link locals are just a curiousity that might or might not work,
depending on the implementation; most of these apply to global addresses
as well, but would require more discussion of the topology. There are
other issues, like being able to inject IPv6 packets with hop limit = 255
from anywhere in the Internet.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
