Dave Crocker wrote:
...
>
> BEC> If you are looking for stable identifiers for "stacks" (in the
> BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely
> BEC> that an FQDN is a safe answer.
>
> It is probably worth noting that the NSRG report uses domain names to label
> the different stacks, in its own examples and in discussion. Whatever the
> reasons for that choice, I obviously find it interesting that they were used
> for that purpose.
As I recall that was a pragmatic choice...
>
> BEC> FQDNs are (mis)used in many ways;
> BEC> a name like www.example.com certainly doesn't identify a given IP stack
> BEC> on a given interface on a given host
>
> 1. When someone starts talking about identifying _interfaces_ I suspect they
> mean address, rather than 'end point identifier'. On the assumption that that
> is not what Brian meant, it's worth having this clarified.
I meant an interface. That could mean a physical interface, or it could mean a
virtual interface such as a tunnel termination or a 6to4 interface. BTW, these
concepts are all made a bit fuzzy by virtualization at level 2. A given Ethernet
address may well refer to different connectors simultaeously, if some level 2
box is doing fancy footwork to distribute transport connections around a server
cluster.
As far a I'm concerned, an address is just a string of bits. Whether it's a
locator or an identifier depends on context. What it locates or identifies
depends on context.
> I'm confused by
> Bill's comment on this: " if there is an entity at a point in the topology,
> then the name maps nicely into the DNS". Domain names are not tied to network
> topology. They are tied to an administrative "topology", which is an entirely
> different thing.
>
> 2. If I understand the concern, here, it is that not _all_ domain names are
> endpoint identifiers. Erik also raised the point that domain names are used
> for different (and inconsistent?) purposes. One might be a host, another a
> service. When there are multiple records returned, they might refer to
> alternative systems or they might be alternate paths to the same service.
>
> My question is: so why does that mean that the ones that _are_ EIDs are
> not acceptable? What problems are caused by having multiple uses?
Possibly none, but exactly the same argument applies to the bit strings
formerly known as address. As Lewis Carroll would perhaps have said, they
mean what we want them to mean.
>
> BEC> I don't see that this has any functional advantage over an IPv6 address
> BEC> for that stack, and it introduces a DNS dependency for the transport layer.
>
> 1. I thought an IPv6 address was an address, not an end-point identifier. No?
No. "Address" is an overloaded concept in IPvN {N=1,4}. They will do just fine
as identifiers if we want.
>
> 2. The concern about introducing a DNS dependency into a lower layer, like
> transport, strikes me as pretty important, too. However, if we invent a new
> construct for an EID, we are a) introducing a new global administration
> requirement, and b) creating a dependency on it in that lower layer. So the
> concern with this new dependency is on the need for an EID, rather than the
> fact that it might be a domain name. No?
If we use "address" bit strings as identifiers, we are *not* adding either
a new administration or a dependency. We are just being a bit clearer about
the double semantics of "addresses" (id and locator).
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
