This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] tftp-hpa 5.0


On Oct  4 13:13, Charles Wilson wrote:
> On 10/4/2010 12:02 PM, Corinna Vinschen wrote:
> > If so, we could do something about that by massaging the returned
> > addresses from V4-in-V6 into plain V4 addresses.  Since the memory
> > region used for V6 can easily contain a V4 address, we don't have
> > to change any memory allocation or so, just tweak the content of the
> > sockaddr structure.  Well, except in case AI_V4MAPPED is specified
> > in getaddrinfo...
> 
> Well, that's basically what happens already.  Incoming V4 packets get
> turned into AI_V4MAPPED ones, always, IIRC -- when the socket was set
> for both V4 and V6.

Erm... hang on.  A socket is created for only one domain/address family,
AF_INET, AF_UNIX, AF_INET6.  There's no such thing as a socket supporting
more than one address family or more than one socket type (stream/dgram).

> It's easier, really, to just FIX the application to fully support V6,
> including the V4 variations.  Otherwise, it doesn't REALLY support V6,
> now does it?

Sure, you're right.

> > Just to let you know, I'll be mostly unavailable for the next five weeks
> > starting this weekend.  If there's something required in terms of the
> > aforementioned V4inV6 problem, the time to do something is either now or
> > late in November.
> 
> If there is an actual problem that requires cygwin changes (which I
> doubt) then Nov is soon enough.
> 
> I don't think it's a good idea for cygwin to automatically  "unwrap"
> v4-in-v6, because we have no (easy) way of knowing if the packet
> ACTUALLY arrived on the v6 interface because somebody ELSE wrapped it
> before it reached our ethernet port, or if Windows wrapped something
> that arrived on the v4 interface, and then presented it to cygwin AS IF
> it arrived on the V6 interface, as a V4-in-V6 packet.
> 
> This "unwrapping" is an application-level decision, IMO.  It just means
> applications with (poorly coded) IPv6 support need additional fixin'
> before it will work as expected on cygwin, in mixed-mode environments.

There's a difference between Linux and Windows, though, which affects
the returned addresses from getaddrinfo, if the AI_V4MAPPED and AI_ALL
flags are set.  In this case Linux returns V6 and V4 addresses, both
formatted in their real address family.  Unless the given host has no V6
address, in which case the V4 addresses are returned as V4inV6
addresses.

On Windows, AI_V4MAPPED | AI_ALL always returns the V4 addresses as
V4inV6 addresses.  I read the SUSv4 getaddrinfo man page, and from
what I can tell both results should be ok:

  "If the AI_V4MAPPED flag is specified along with an ai_family of
   AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
   on finding no matching IPv6 addresses
   [...]
   If the AI_ALL flag is used with the AI_V4MAPPED flag, then
   getaddrinfo() shall return all matching IPv6 and IPv4 addresses."

As you can see, the text does not specify that in the AI_V4MAPPED |
AI_ALL case the IPv4 addresses should be returned in a given address
family.  This *could* be changed in Cygwin to follow the Linux
behaviour.

However, I have no idea if that affects your case, of course...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]