Subject: Does every host need a FQDN name in the future?//re:[RRG] draft-rja-ilnp-intro-01.txt

From: xuxiaohu 41208 <[email-masked]>
Date: Fri, 01 Aug 2008 12:35:12 +0100

> Reading the ILNP intro draft, I was already trying to remember the 
> 
> locations/identities [*] of the most damning evaluations of 
> GSE/8+8  
> when this caught my eye:
> 
>    Identifiers are unique within the context of a given
>    Locator; in many cases, Identifiers might happen to be
>    globally unique, but that is not a functional requirement
>    for this proposal.
> 
> This means that it won't be possible to learn the locators for a 
> given  
> identifier through a lookup mechanism. So ILNP has many of the 
> same  
> limitations of shim6: at least one working (!) locator must be 
> present  
> in the DNS (or other address discovery mechanism).
> 
> Because of this and the use of dynamic DNS, basically, the FQDN is 
> the  
> real identifier while the "I" is only a fixed-size handle that  
> conveniently fits in existing fields.

I also believe so. then my question is Does every host need a FQDN name in the future?

Xiaohu XU

> 
> It also shares with shim6 the limitation that locators are exposed 
> all  
> the way to the hosts, so it's highly likely that someone will 
> filter  
> on them so it doesn't solve or avoid the renumbering problem.
> 
>    When one upstream connection
>    fails, the node sends an ICMP Locator Update message to each
>    existing correspondent node to remove the no-longer-valid
>    Locator from the set of valid Locators.
> 
> This mechanism doesn't address the situation where there is a 
> failure,  
> but the failure isn't directly visible to the host (or router)  
> connecting to the link in question. Because of switches, failures 
> on  
> the actual link are often hidden. There can also be a problem 
> reaching  
> part of the internet through a link, so the fact that one 
> destination  
> is reachable doesn't mean that another destination is reachable. 
> So  
> the only way to know for sure if a destination is reachable is to 
> have  
> specific information in the routing system, or send packets and 
> see if  
> something comes back.
> 
> Obviously sending ICMP messages over the failed link doesn't work, 
> and  
> using another link creates security issues.
> 
> Although it doesn't look that way on the surface, this is fairly  
> similar to shim6 in what it does, except that shim6 is much more  
> complete and backward compatible.
> 
> [*] http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-ipngwg-
> esd-analysis-05.txt
> 
> --
> to unsubscribe send a message to [email-masked] with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
> 

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Tony Li" <[email-masked]>
Date: Fri, 1 Aug 2008 12:55:53 +0100

|I also believe so. then my question is Does every host need a 
|FQDN name in the future?

It would seem like it would be no different than today.  If one had a host
without a FQDN, then you would need to refer to it using a full 128 bit
locator and identifier.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 05 Aug 2008 17:30:17 +0800

> without a FQDN, then you would need to refer to it using a full 128 bit

Provided there are some hosts without FQDNs, does that mean we need a
separate id/locator resolution infrastructure except the current DNS system?

Xiaohu XU

---

From: "Tony Li" <[email-masked]>
Date: Tue, 5 Aug 2008 09:57:26 -0700

|> It would seem like it would be no different than today.  If 
|one had a host
|> without a FQDN, then you would need to refer to it using a 
|full 128 bit
|> locator and identifier.
|
|Provided there are some hosts without FQDNs, does that mean we need a
|separate id/locator resolution infrastructure except the 
|current DNS system?

Not at all.  Such systems would be reachable via their explicit /128, just
like today.  This is just pure legacy IPv6 functionality.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2008 10:39:55 +1200

> like today.  This is just pure legacy IPv6 functionality.

<obscenity>

You can always fabricate a synthetic FQDN-like name for such an
address, if a new FQDN-based API requires it. Mine right now could be
200282d8267c00000000000082d8267c.map6.arpa for example.

</obscenity>

   Brian

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 06 Aug 2008 09:58:21 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Tony Li
> 发送时间: 2008年8月6日 0:57
> 收件人: 'Xu Xiaohu'; 'Iljitsch van Beijnum'
> 抄送: 'rrg Group'
> 主题: RE: Does every host need a FQDN name in the future?//re:[RRG]
> draft-rja-ilnp-intro-01.txt
> 
> 
> 

Hi Tony,

Taking the mobility and multi-homing into account, do you still believe it
is workable?

Xiaohu Xu

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 06 Aug 2008 10:03:59 +0800

> 200282d8267c00000000000082d8267c.map6.arpa for example.

Hi Brian

This idea is workable as ENUM. However, I wonder who will manage those
mapping entries?

Xiaohu XU

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2008 14:27:42 +1200

> This idea is workable as ENUM. However, I wonder who will manage those

They don't need managing; they aren't really in the DNS, but are purely
synthetic. (Which means they can't be validated with DNSSEC and there
will be no reverse DNS.) But a resolver could be faked to "resolve"
them into a AAAA reply.

It's a horrible idea ;-)

   Brian

---

From: "Tony Li" <[email-masked]>
Date: Tue, 5 Aug 2008 21:37:07 -0700

|Taking the mobility and multi-homing into account, do you 
|still believe it
|is workable?

I haven't seen a reason why it wouldn't be.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 06 Aug 2008 13:16:37 +0800

> I haven't seen a reason why it wouldn't be.

Once the 128 bit address is split into locator and identifier and the
locator will change according to the current network location, how could you
know the locator part before doing some resolution in the id/locator mapping
system (assume no such system) or DNS system (since this host has no FQDN
name)? 

Xiaohu XU

---

From: "Tony Li" <[email-masked]>
Date: Tue, 5 Aug 2008 23:11:48 -0700

|Once the 128 bit address is split into locator and identifier and the
|locator will change according to the current network location, 
|how could you
|know the locator part before doing some resolution in the 
|id/locator mapping
|system (assume no such system) or DNS system (since this host 
|has no FQDN
|name)? 

It's not clear to me that you ever have to do a pure identifier to locator
lookup.  This is especially true since locators are only locally unique.

Thus, you always need to have a locator identifier pair before starting a
lookup, presumably to determine alternate locators.  Once you have the first
pair, you could do a reverse lookup to determine a name (and any name will
do) and then do a forward lookup to determine the locator set.

Note that I don't know if this is what Ran has in mind, but it could work.

Tony

---

From: Christian Vogt <[email-masked]>
Date: Wed, 6 Aug 2008 12:16:29 +0300

Hi Brian -

> They don't need managing; they aren't really in the DNS, but are
> purely synthetic. (Which means they can't be validated with DNSSEC and
> there will be no reverse DNS.) But a resolver could be faked to
> "resolve" them into a AAAA reply.
>
> It's a horrible idea ;-)

Why is it a horrible idea?  I would say it is a straightforward and
practical method to support hosts without a real hostname when
hostnames are used as identifiers.

As I mentioned during the RRG session in Dublin as well as in an
earlier post [1] to this mailing list, we should re-consider whether
there really is a need for another ID/locator split in addition to the
existing hostname/address split.  I do not believe there is.  We would
get all the benefits we are after if we re-used the existing
hostname/address split, and moved the splitting point from between the
application layer and the transport layer down to between the
transport layer and the IP layer.

When we get to the engineering stage, we would need to work out three
auxiliary methods:

(1) to generate synthetic hostnames for hosts without a real hostname

(2) to support legacy transport protocols

(3) to communicate hostnames to correspondent hosts

Synthesizing a hostname based on an address, as you are suggesting, is
IMHO a very reasonable solution for (1).

A simple and secure solution for (2) would be to hash an arbitrary-
length hostname into 128 bits and use this in legacy transport
protocols -- just like HIP is generating 128-bit HITs from
arbitrary-length keys.

A cool solution for (3) could be the combination of (i) an initial
explicit exchange of hostnames between peers, and (ii) Noel's proposal
to compute checksums based on identifiers (hostnames, in this case)
for subsequent packets.

- Christian

[1] http://www.ops.ietf.org/lists/rrg/2008/msg01912.html

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Aug 2008 11:20:26 +0200

> lookup.  This is especially true since locators are only locally  

Locators are only locally unique? Isn't the whole point of a locator  
to get you where you want to be, not to a location which may or may  
not be the one you wanted to be but with the same name as the one  
where you want to be?

In my opinion, non-unique identifiers are not really any better than a  
locator/identifier overload like we have today. Maybe it can be made  
to work, but you're forever stuck with accommodating this limitation.

Case in point: shim6. It doesn't support setting up sessions if you  
don't have a working locator because it can't do an identifier-to- 
locator lookup.

> do) and then do a forward lookup to determine the locator set.

In other words: the FQDN is the real identifier and the value in the  
bottom 64 bits of the address field is meaningless.

Note that reliably providing reverse lookup DNS service with IPv6  
isn't entirely trivial.

---

From: Steven Blake <[email-masked]>
Date: Wed, 06 Aug 2008 10:00:51 -0400

On Wed, 6 Aug 2008 11:20:26 +0200 Iljitsch van Beijnum <[email-masked]>
wrote:

> >  It's not clear to me that you ever have to do a pure identifier to
locator lookup. This is especially true since locators are only locally
unique. 
>
> Locators are only locally unique? Isn't the whole point of a locator to
get you where you want to be, not to a location which may or may not be the

> one you wanted to be but with the same name as the one where you want to
be?

I'm not sure what Tony has in mind with "locally unique" locators.  Maybe
he is thinking of the case where a site uses localized addressing (e.g.,
ULAs)
and re-writes source locators on the site border router?

> In my opinion, non-unique identifiers are not really any better than a
locator/identifier overload like we have today. Maybe it can be made to
work, 
> but you're forever stuck with accommodating this limitation.

There's no way to enforce global uniqueness of the I bits, even if you
wanted to.  The best you can do is not provide any incentives to hijack
someone 
else's.

> Case in point: shim6. It doesn't support setting up sessions if you don't
have a working locator because it can't do an identifier-to-locator lookup.
>
> >  Thus, you always need to have a locator identifier pair before
starting a lookup, presumably to determine alternate locators. Once you
have the first 
> >  pair, you could do a reverse lookup to determine a name (and any name
will do) and then do a forward lookup to determine the locator set.

The FQDN is the rendezvous identifier, the I field is the invariant
identifier for a host between a set of (possibly dynamic) locators.  You
could 
possibly engineer things so that the I field did not have to be constant
across a set of locators a host is reachable by, but that would be really
ugly.

> Note that reliably providing reverse lookup DNS service with IPv6 isn't
entirely trivial. 

Regards,

// Steve

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 6 Aug 2008 10:37:09 -0400 (EDT)

> From: "Tony Li" <[email-masked]>

     >> Once the 128 bit address is split into locator and identifier 

    > This is especially true since locators are only locally unique.

Err, did you mean 'the locator part of a split IPv6 address only identifies a
local scope, not necessarily an individual interface'? (A locally-unique
locator would only be usable within the scope in which it is unique - which is
not that useful, so your original wording doesn't make sense to me.)

	Noel

---

From: Christian Vogt <[email-masked]>
Date: Wed, 6 Aug 2008 18:54:21 +0300

> I'm not sure what Tony has in mind with "locally unique" locators.

Was probably just a typo and should be "locally unique identifier".

Since a locally unique identifier is, on a global scope, meaningless  
without
its corresponding locator, referrals must always point to pairs of  
identi-
fiers and locators.  Hence no need for a pure identifier-to-locator  
lookup.

- Chris

---

From: "Tony Li" <[email-masked]>
Date: Wed, 6 Aug 2008 09:48:26 -0700

|> >  It's not clear to me that you ever have to do a pure identifier to
|locator lookup. This is especially true since locators are only locally
|unique. 
|
|I'm not sure what Tony has in mind with "locally unique" 
|locators.  

Clearly, my alleged mind had nothing to do with it.  ;-)

I meant to say: "This is especially true since identifiers are only locally
unique."

Doh!  Apologies.  Engage mind BEFORE releasing the clutch.  Sigh.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Aug 2008 19:29:16 +0200

> Doh!  Apologies.  Engage mind BEFORE releasing the clutch.  Sigh.

The sad thing is that non-unique locators aren't the strangest thing  
that has been proposed here so I didn't even consider the possibility  
of a mistake...

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 07 Aug 2008 12:22:25 +0800

> I meant to say: "This is especially true since identifiers are only
locally

Tony,

I'm confused by what you said. In Noel's Endpoint Name draft, the first
requirement for the host identifier is global uniqueness. Is that wrong? Or
you just want to use the locator identifier pair together as a globally
unique identifier. Then should this pair keep stable in a long run just like
the home address in mobile IP?

Xiaohu XU

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 6 Aug 2008 22:12:31 -0700

On Aug 1, 2008, at 4:35 AM, xuxiaohu 41208 wrote:

>> GSE/8+8 when this caught my eye:
>>
>> given identifier through a lookup mechanism. So ILNP has many of the
>> same limitations of shim6: at least one working (!) locator must be
>> present in the DNS (or other address discovery mechanism).
>>
>> the real identifier while the "I" is only a fixed-size handle that

Looks like this question by Xiaohu has triggered  a number of  
exchanges in the last few days. As a side observer, it seems to me  
there is a fair amount of "cross talk", perhaps partly due to unclear  
context.

First, the above discussion refers to ILNP-enabled hosts, and I would  
expect that ILNP-enabled hosts do have a FQDN name (so the question  
itself seems an unnecessary generalization).

Second, the above question came from the discussion of draft-rja-ilnp- 
intro-01.txt, yet Xiaohu's last msg asked

    I'm confused by what you said. In Noel's Endpoint Name
    draft, the first requirement for the host identifier is
    global uniqueness. Is that wrong?

As I read it, Tony's comment referred to ILNP draft, yet the above  
question seems forgotten where it was originated.

Lixia

---

From: "Tony Li" <[email-masked]>
Date: Wed, 6 Aug 2008 22:20:21 -0700

|I'm confused by what you said. In Noel's Endpoint Name draft, the first
|requirement for the host identifier is global uniqueness. Is 
|that wrong? 

You'd have to ask Noel.  Ran clearly disagrees.  FWIW, our earlier
experiences with GSE point to the fact that truly achieving guaranteed
global uniqueness is already hard.  The best that we can easily do is
statistical uniqueness.

|Or
|you just want to use the locator identifier pair together as a globally
|unique identifier. Then should this pair keep stable in a long 
|run just like
|the home address in mobile IP?

Again, Ran is specifying that the identifier be locally unique, so yes, the
(L, I) pair should be globally unique.  I make no claims about its
stability, especially in the face of roaming.  Again, you should ask Ran,
it's his proposal.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 6 Aug 2008 22:24:00 -0700

On Aug 6, 2008, at 2:16 AM, Christian Vogt wrote:

> ......
> existing hostname/address split.  I do not believe there is.

"the mind is like parachute, it works best when it is open" -- I  
picked this up from a 8th grader.

it is natural that different people may see different pictures, it is  
also beneficial to try to see the picture from different views.

it is very true that good use of DNS names can help solve many  
problems, as  reasoned below, however this is not equivalent to a  
proof of node-ID being unnecessary.  HIP is used today, maybe it is  
beneficial to find out why people use HIP first.

>  We would

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 07 Aug 2008 14:23:13 +0800

Hi Tony,

Thanks a lot for your clarification. I think I'd better to ask Ran since he
disagrees with the above requirement ;)

Xiaohu XU

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2008 10:38:00 +0200

On 7 aug 2008, at 7:20, Tony Li wrote:

> FWIW, our earlier

I don't see that. If you're going to use the ID as a key in a  
hierarchical mapping service, then the people in charge of the  
relevant part of the namespace can determine who is allowed in and who  
isn't. That's why we don't have any uniqueness issues with the DNS.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 07 Aug 2008 16:58:19 +0800

>>hierarchical mapping service, then the people in charge of 
>>the relevant part of the namespace can determine who is 
>>allowed in and who isn't. That's why we don't have any 
>>uniqueness issues with the DNS.

I am with Ilji. A well-organized hierarchical system can easily guarantee global
uniqueness. Every level can control it only assigns unique prefix to next level
within its only prefix pool. Both FQHN and IP address are good examples, which have
achieve global uniqueness. It is only difficult if we want to achieve global
uniqueness with pure flat structure, like current HIT. Now, the point is whether
statistical uniqueness is enough. If the answer is no, change the structure.

Sheng

---

From: Steven Blake <[email-masked]>
Date: Thu, 07 Aug 2008 07:57:34 -0400

> isn't. That's why we don't have any uniqueness issues with the DNS.

In ILNPv6, the ID is not used as a key in any mapping service.

Regards,

// Steve

---

From: Steven Blake <[email-masked]>
Date: Thu, 07 Aug 2008 08:08:18 -0400

> statistical uniqueness is enough. If the answer is no, change the structure.

IPv6 addresses are only guaranteed to be unique because if two host
interfaces on the same link happen to share the same IID, then Neighbor
Discovery breaks and the first-hop router cannot resolve who to send
packets to.

The exact same property holds for any 8+8 scheme.

As long as hosts are allowed to autoconfigure the lower 8 bytes of their
address field, then it is not possible to guarantee global uniqueness
for that part of the address.  The best that can be accomplished is to
ensure that nothing breaks if two hosts in the Internet happen to share
the same value for those 8 bytes.

Regards,

// Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2008 14:52:31 +0200

> the same value for those 8 bytes.

I maintain that having a non-unique identifier in all packets doesn't  
buy us anything useful:

- can't use it to identify correspondents, so additional  
identification necessary
- can't filter on it, so this will be done on locators = no  
renumberability
- can't look locators up using the id, so a working locator must  
always accompany id = reduced multihoming and mobility

And having to update transport protocols certainly costs us a lot.

---

From: "Tony Li" <[email-masked]>
Date: Thu, 7 Aug 2008 09:06:11 -0700

|I don't see that. If you're going to use the ID as a key in a  
|hierarchical mapping service, then the people in charge of the  
|relevant part of the namespace can determine who is allowed in 
|and who  
|isn't. That's why we don't have any uniqueness issues with the DNS.

Correct.  If you want global uniqueness, you have to have a globally managed
namespace.  Previously, GSE proposed using IEEE 802 MAC addresses as
identifiers.  Because there are incidents where these addresses have been
duplicated, this 'easy' solution was discounted as being truly unique.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Thu, 7 Aug 2008 09:10:02 -0700

Hi Iljitsch,

|I maintain that having a non-unique identifier in all packets doesn't  
|buy us anything useful:
|
|- can't use it to identify correspondents, so additional  
|identification necessary

Such as the locator, which is already at hand.

|- can't filter on it, so this will be done on locators = no  
|renumberability

The local site *can* guarantee that an identifier is unique, so it can in
fact filter on inbound identifiers.  Filtering on remote identifiers is
trivially insecure (regardless of uniqueness) due to spoofing.

|- can't look locators up using the id, so a working locator must  
|always accompany id = reduced multihoming and mobility

I'm failing the logical leap here.  Could you spell out where this is a
problem?

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2008 19:32:24 +0200

> trivially insecure (regardless of uniqueness) due to spoofing.

The id/loc overload allows for a return routability check;  
cryptographic identifiers allow for a challenge.

> I'm failing the logical leap here.  Could you spell out where this  

If you find yourself in the situation where the currently known  
locator(s) are unreachable, you can't ask the other side for locators.  
If you also can't look them up, you can't contact the correspondent  
through another locator and the session is dead or can't be  
established. With mobility this is especially likely as a mobile host  
will often not know its new locator before the old one stops working.

In theory a locator->locator lookup would be possible, maybe through  
the DNS. In that case, the ID value is superfluous.

Maybe we should simply deprecate identifiers. After all, I know who I  
am and you know who you are, and the packets get there through the  
locators. And if identity is really necessary, higher layers can  
manage it (TLS etc).

---

From: "Tony Li" <[email-masked]>
Date: Thu, 7 Aug 2008 10:51:37 -0700

Hi Iljitsch,

|> |- can't filter on it, so this will be done on locators = no
|> |renumberability
|
|> The local site *can* guarantee that an identifier is unique, so it  
|> can in
|> fact filter on inbound identifiers.  Filtering on remote 
|identifiers  
|> is
|> trivially insecure (regardless of uniqueness) due to spoofing.
|
|The id/loc overload allows for a return routability check;  
|cryptographic identifiers allow for a challenge.

True, but now we're drifting into the realm of how much security is provided
just by filtering.  My strong preference is that if you want security, it
should be provided by real crypto, not just by identifier filtering.  Again,
spoofing identifiers is going to happen.

|> |- can't look locators up using the id, so a working locator must
|> |always accompany id = reduced multihoming and mobility
|
|> I'm failing the logical leap here.  Could you spell out where this  
|> is a
|> problem?
|
|If you find yourself in the situation where the currently known  
|locator(s) are unreachable, you can't ask the other side for 
|locators.  
|If you also can't look them up, you can't contact the correspondent  
|through another locator and the session is dead or can't be  
|established. With mobility this is especially likely as a mobile host  
|will often not know its new locator before the old one stops working.
|
|In theory a locator->locator lookup would be possible, maybe through  
|the DNS. In that case, the ID value is superfluous.

Except that the locator isn't host-specific.  As before, you could
conceivably do a reverse lookup on (locator, id) -> name -> {locator} to get
the new set of locators.

|Maybe we should simply deprecate identifiers. After all, I know who I  
|am and you know who you are, and the packets get there through the  
|locators. And if identity is really necessary, higher layers can  
|manage it (TLS etc).

Or, perhaps, you're taking Christian's side that the real identifier is the
FQDN.  The locally unique identifier is simply a form of a nonce.  ;-)

Tony

---

From: Steven Blake <[email-masked]>
Date: Fri, 08 Aug 2008 08:40:18 -0400

> locators. And if identity is really necessary, higher layers can  

If I understand what you have in mind, this solution would look like shim6
(i.e., host has multiple addresses, each with different IIDs).

Please correct me if I am wrong, but shim6 does not support either (1) mobility or
(2) transparent (to transport layer) stateless network locator translation, correct?

I can imagine how shim6 could be made to work for mobility, but I can't
imagine how it can be made to work with network locator translation,
without turning it into an 8+8 scheme.

Regards,

// Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Aug 2008 16:02:15 +0200

> (i.e., host has multiple addresses, each with different IIDs).

The interface identifiers are derived from a hash that is the same for  
all addresses with HBA so even though they may be different, they do  
have a verifiable relationship. (It would have been easier if they  
were all the same for the purposes of rewriting the top 64 bits of the  
address.)

> Please correct me if I am wrong, but shim6 does not support either  
> (1) mobility

No.

> or

Not sure what you mean by that. If the question is "will shim6 work  
through NAT" then the answer is "no".

> without turning it into an 8+8 scheme.

shim6 is what you get when you start with 8+8 and add the things that  
are missing that are needed to make it useful and deployable. You  
could consider shim6 to be a form of "16+16".

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Aug 2008 11:23:53 +1200

> FQDN.  The locally unique identifier is simply a form of a nonce.  ;-)

No ;-) needed, I think. An identifier needs to be unique for as long as
it needs to be unique for. If we stipulate that no transport connection
has a lifetime greater than T, then the transport ID only needs
to be unique for T+epsilon. (Where lifetime means the time after which
all ends of the connection have deleted all relevant state.) So you can
imagine a world in which the FQDN is used in a discovery phase to get
a fresh unique transport ID and a set of locators that currently
reach that transport ID.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Mon, 11 Aug 2008 15:58:19 -0400

On 8/7/08 1:32 PM, Iljitsch van Beijnum allegedly wrote:
> through another locator and the session is dead or can't be established. 
> With mobility this is especially likely as a mobile host will often not 
> know its new locator before the old one stops working.
> 
> In theory a locator->locator lookup would be possible, maybe through the 
> DNS. In that case, the ID value is superfluous.
> 
> Maybe we should simply deprecate identifiers. After all, I know who I am 
> and you know who you are, and the packets get there through the 
> locators. And if identity is really necessary, higher layers can manage 
> it (TLS etc).

You can't deprecate identifiers in general.  We need identifiers for 
mobility and for multipath transport.  They don't need to be permanent, 
and they can be exchanged after initial contact is established, but they 
do need to be unique and stable for the duration of a session, 
independent of anything that might change with topological location.

On 8/10/08 7:23 PM, Brian E Carpenter allegedly wrote:
> to be unique for T+epsilon. 

Except that sessions overlap, so if it's a system-wide identifier it has 
to persist until the next reboot (because new sessions will keep picking 
it up and using it before previous sessions are done with it).  If it's 
only a session-level identifier it can be more evanescent.  This would 
make the multipath design more interesting.

swb

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Aug 2008 23:19:43 +0200

On 11 aug 2008, at 21:58, Scott Brim wrote:

> mobility and for multipath transport.

Two things that don't exist in the real world today...

So no need for those to hold us back.

And don't MIPv6, SCTP and TCP-over-shim6 all use regular IP addresses  
that come with locator functionality as their ID?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Aug 2008 09:47:58 +1200

On 2008-08-12 07:58, Scott Brim wrote:
...
> make the multipath design more interesting.

That's why I specifically said "transport ID". Not host ID. Our thinking
has been somewhat constrained by the TCP/IP assumptions that
transport ID = network ID + port number, and that network ID = host ID
= host locator.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Tue, 12 Aug 2008 13:01:07 -0400

> that come with locator functionality as their ID?

You want something that is stable despite changes in topological 
location.  As Brian says, MIP uses the home address as an identifier -- 
an anchor point for authentication.  I don't know mobile SCTP or shim6 
very well (help?) but they seem to use a similar stable anchor point. 
It seems that none of these use a pure network layer identifier.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Aug 2008 09:47:07 +1200

On 2008-08-13 05:01, Scott Brim wrote:
> very well (help?) but they seem to use a similar stable anchor point. It
> seems that none of these use a pure network layer identifier.

I can't quite parse "mobile SCTP or shim6". I can say nothing about
mobile SCTP, but if you mean "mobile (SCTP or shim6)", then there's
no such thing as mobile shim6 - the assumption is that shim6 applies
to a site, and a shim6-based transport session is anchored by an
arbitrary choice of locator-address for the host concerned, within one
of the site's prefixes. So this explicitly builds on the wave/particle
duality of IP addresses.

(Shim6/Mobile IPv6 interaction is officially for further study,
see expired draft draft-bagnulo-shim6-mip.)

    Brian