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

[xuxiaohu 41208 <xuxh@huawei.com>]

> 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 rrg-request@psg.com 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 rrg-request@psg.com 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