Re: [tae] [tsv-area] Transport negotiation

On Dec 3, 2008, at 14:35, Joe Touch wrote:
>
> I'd say a transport layer is defined as the first protocol header in  
> the
> payload of the network header addressed to the host. That is typically
> the innermost IP packet, but not always.

Fair enough, I suppose.

> I disagree; keep in mind that port number assignments aren't IP- 
> version
> specific, so if a service is assigned to port A, then it is assigned  
> to
> port A for IPv4 and IPv6. I see no reason why SRV records should  
> either
> support or encourage a network-protocol specific port number for a  
> given
> service.

Not all services need to be assigned port numbers by IANA.  It's  
perfectly reasonable to define a service name with no associated port  
number.  Servers can bind to temporary port numbers and register them  
in DNS with service records.  Sadly, dual-stack IPv4/IPv6 servers  
cannot always ensure availability over both IPv4 and IPv6 at the same  
temporary port.  For example, consider the case where the IPv4 side of  
the service is mapped through a NAT gateway, e.g. it's located on a  
residential network and advertising its availability with DNS-SD to  
the public Internet.

If you don't believe in such configurations and you want to discourage  
them, then keeping SRV unified for both IPv4 and IPv6 makes a lot of  
sense.  The net result, however, is that dual-stack servers likely  
will be advertised with DNS-SD for IPv4 only, i.e. not for IPv6, for  
the foreseeable future.  This is how Apple's implementation of DNS-SD  
works today, and the result is slower adoption of IPv6 as an  
alternative to IPv4/NAT.  Moreover, it's doubtful that anything can be  
done to remedy the problem without drawing the network protocol  
distinction between service records some other way-- a way that will  
probably be more evil than my previous idea.

--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering

_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae