Identifiers in the data stream [Re: Default security functions on an IPv6 CPE]

[S.P.Zeidler]

Thus wrote Brian E Carpenter (brian.e.carpenter at gmail.com):

> On 2011-06-03 05:39, Steinar H. Gunderson wrote:
> > [...] For sure, BitTorrent, Skype, and lots of different
> > gaming protocols do this, and are in wide use. After all, how else
> > would you initiate peer-to-peer communication?
> 
> Yes. This is a major wart on the Internet and will get significantly worse
> now that we are deploying a second address family (therefore, it's almost an
> ipv6-ops issue).

Correct me if I'm wrong, but isn't that being done to cope with NAPT, and
could be ceased if the address that arrived at the referral server was an
address that a peer could talk to? I.e. it would be no longer needed in a
IPv6 world?

Of course an answer to "tell me my peers" still would contain addresses
(or FQDNs), but a host would no longer need to convey its own address(es).

> Over in another universe, there's
> http://tools.ietf.org/html/draft-carpenter-referral-ps
> but it has proved very hard to persuade the IETF that this
> is a serious problem.

s/thrid-party/third-party/
s/disciver/discover/

Interface selection would need auth or it becomes a man-in-the-middle
attackers dream. I'd assume that the referral itself was adequately
authenticated anyway.

Adding too many dimensions of preference to connectivity information will
likely make the result too complicated and too often wrong (who, eg, will
enter cost? how does a program know if a connection is metered or flat
fee?). A simple preference policy is more likely to be correct.

I agree that using a FQDN is a less reliable solution for most clients,
ie not-public-servers. Referral-by-DNS OTOH also happens (see eg MX),
generally to public servers.

Are there situations in a net that only has 1:1 mappings where addresses
that both made it to one referral server couldn't talk to each other?
(Firewalls and games in the DFZ excluded).
If not, it would seem easiest to let the reference be something simple
that works, and afterwards let the partners of the communication
handshake on optimizations, I'd say.

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)