I think the point Ken was making, which I agreed with, is that when you are
sending to an IPv4 destination address, you have to use an IPv4 source
address. And when you are sending to an IPv6 destination address, you have
to use an IPv6 source address.
I think the point you are making is that according to
draft-ietf-ngtrans-siit-07.txt, there will be cases where an IPv6 node will
be sending an IPv6 packet to an IPv4-mapped IPv6 destination address. In
other words, IPv4-mapped IPv6 addresses can appear on the wire in IPv6
packets.
This means that my draft can not unambiguously use IPv4-mapped addresses as
a convenient representation for IPv4 addresses. Sigh.
[Btw, won't this be a big source of confusion for applications? I can forsee
an app that supports both IPv6 & IPv4 doing a getpeername on an IPv6 socket
and getting back an IPv4-mapped address - might this lead to problems, like
the app thinking the socket is sending IPv4 packets???]
Here is one possible fix (maybe an improvement, actually) that occurs to me:
a) the policy table only contains policies for IPv6 addresses, not IPv4
addresses
b) so remove all the IPv4-mapped policies from the policy table
c) the source address selection algorithm only applies to IPv6 addresses.
candidate set definition does not need to say anything about IPv4-mapped
addresses.
d) the destination address selection algorithm (which is dealing with both
IPv4 and IPv6 destination addresses) still has a need to know what IPv4
source address will be used for an IPv4 destination address
e) but this IPv4 source address selection is left unspecified in my draft
Comments?
Rich
> -----Original Message-----
> From: Brian Zill
> Sent: Friday, September 08, 2000 8:46 PM
> To: Richard Draves; 'Powell, Ken'
> Cc: [EMAIL PROTECTED]
> Subject: RE: draft-ietf-ipngwg-addr-select-01 comments
>
>
> > > Page 6, Section 3
> > >
> > > Should an additional restriction like the following be
> > > added to the candidate set of source addresses?
> > >
> > > "For IPv4 Mapped destination addresses, the set of
> > > candidate source addresses must only include IPv4 Mapped
> > > addresses. For any other destination address, the set
> > > of candidate source addresses MUST NOT include IPv4
> > > Mapped addresses."
> >
> > Yes.
>
> No :-)
>
> In the first quoted sentence, the set of candidate source
> addresses must also include IPv4 *Translated* addresses, or
> nodes in a SIIT cloud won't work. And on the other end,
> translators need to be able to send from IPv4 Mapped
> addresses to IPv4 Translated addresses.
>
> So how about:
>
> "For IPv4 Mapped destination addresses, the set of
> candidate source addresses must only include IPv4
> Mapped and IPv4 Translated addresses. For any other
> destination address, the set of candidate source
> addresses MUST NOT include IPv4 Mapped addresses."
>
> Note I didn't change this to regulate the use of IPv4
> translated addresses as destination addresses, since a node
> inside a SIIT cloud should be able to talk to other local
> nodes using its translated address even if the other node has
> a regular (i.e. non-translated IPv4) IPv6 address. Or at
> least I believe it should. However, I think allowing this
> means that for source address selection purposes, IPv4
> translated addresses should get less preference than global
> addresses - they're essentially a weird kind of site-local addresses.
>
> But if you wanted to restrict the use of translated addresses
> just to communication with the translator, you could say
> something like:
>
> "For an IPv4 Mapped or IPv4 Translated destination
> address, the set of candidate source addresses must
> only include IPv4 Mapped and IPv4 Translated addresses.
> For any other destination address, the set of candidate
> source addresses MUST NOT include IPv4 Mapped addresses
> or IPv4 Translated addresses."
>
> But my vote's for my first one.
>
> --Brian
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
