Re: Reinventing Site-Locals (Re: easy to remember addresses and /etc/hosts and DNS)

[Brian E Carpenter <[e-mail]>]

On 27-Apr-19 14:19, Mark Smith wrote:
> On Fri, 26 Apr 2019 at 21:36, Alexandre Petrescu
> <[e-mail]> wrote:
>>
>>
>>
>> Le 26/04/2019 à 12:05, Mark Smith a écrit :
>>> On Fri, 26 Apr 2019 at 19:54, Alexandre Petrescu
>>> <[e-mail]> wrote:
>>>>
>>>>
>>>>
> 
> <snip>
> 
>>>>>>
>>>>>> But think about three cars in a covoy; the convoy is disconnected from
>>>>>> the IPv6 Internet, yet fully connected on IPv6 between all computers in
>>>>>> the convoy.  Which of the cars should host the DNS server?
>>>>>>
>>>>>
>>>>> All of them.
>>>>
>>>> Mark,
>>>>
>>>> Thank you very much for the suggestion.  I will consider it.
>>>>
>>>> I would like to ask you: is multicast DNS (mDNS) working on a single
>>>> subnet only?  Or does it work across subnets?
>>>>
>>>
>>> I'm not an expert in mDNS or related, have just read enough to know
>>> what problem they're solving and (very) roughly how it works.
>>>
>>> DNS Service Discovery is intended to convey that information across subnets:
>>>
>>> http://www.dns-sd.org/
>>
>> I suppose DNS Service Discovery works ok on IPv6, and over multiple
>> subnets, and that it relies on the proper use of IPv6 multicast routing
>> protocols.
> 
> No, I'm pretty sure it doesn't. It's designed to be able to work over
> the Internet, so no multicast required.

Correct. I played with it a bit as a peripheral aspect of the ANIMA WG and both unicast DNS and mDNS could be used. There are examples like _printer._sub._http._tcp.dns-sd.org. around for testing.

    Brian

>> I never tried IPv6 multicast routing protocols on links
>> involving OCB (a kind of stripped ad-hoc WiFi at 5.9GHz).
>>
>> I suppose the use of DNS resolver address in RA is also an option in
>> this space.  I have tried this DNS-in-RA and it works ok.
>>
>> Whether DNS-in-RA, DNS-SD and mDNS should be used in cars, and how, can
>> be a subject of debate.  There is a Problem Statement draft in the
>> IPWAVE WG that lists in section "DNS Naming Service" some considered
>> problems.
>>
>> Until these things get fixed (how to use DNS in car convoy?) I need the
>> manual configuration of easy to remember link-local addresses
>>
> 
> It will be much easier to adapt existing name and resource discovery
> methods and protocols to your problem space than to get RFC4291
> updated to include a unique subnet ID in Link-Local addresses.
> 
>> When DNS works in car convoys, I expect other inconvenients using
>> name-to-address mappings compared to IP address literals.
>>
> 
> You need to read "The Design of Everyday Things" if you think typing
> in IP address literals is more user friendly than device names.
> 
> https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things
> 
> 
> The importance if giving names to devices instead of expecting users
> to remember numbers has been recognised for at least as long as the
> last 47 years, when the ARPA Network only had 20 hosts on it, and
> single octet addresses -
> 
> RFC 226, "STANDARDIZATION OF HOST MNEUMONICS", 20 SEPT 71.
> 
> 
> Discovery of services and resources with names on the network is as
> least as old as 1982 -
> 
> (Xerox) "Grapevine: An exercise in distributed computing"
> http://birrell.org/andrew/papers/Grapevine.pdf
> 
> 
>> I might need to update the DNS servers' files with new IPv6 Link-Local
>> address to name mappings, whenever a faulty interface is replaced, or
>> when USB interface keys are moved, or when 1Gb Ethernet cards are
>> migrated to 10Gb Ethernet.
>>
>> If I am to update files, why not updating rather the computer startup
>> scripts (not DNS)?  These computer startup scripts are present in all
>> computers, including embedded, as unencumbered and open source.
>>
>> Second,
>>
>> If I use DNS names I must remember a name like:
>> front-Lead-First (means the IP address on the front bumper of the
>>                    Follower, in the subnet between Lead and First
>>                    Follower)
>> rear-Lead-First
>> front-First-Second
>> rear-First-Second
>> etc.
>> These names are too long to type.  So I would abbreviate them to:
>> flf
>> rlf
>> ffs
>> rfs
>> etc.
>>
>> These flf, rlf, etc are no less cryptic than a literal like fe80:1::1 is.
>>
>> The short IP address literals are loved and understood by more people.
>>
> 
> A test for you. Which would you find easier to remember?
> 
> This series of numbers?
> 
> 821
> 826
> 791
> 1035
> 
> 
> 
> or this series of acronyms and what they stand for?
> 
> SMTP
> ARP
> IP
> DNS
> 
> 
>>>> (because the numerous computers in these three cars are not all on a
>>>> single subnet; they are all interconnected with IP, but there are
>>>> multiple subnets with routers in between).
>>>>
>>>
> 
> Right. This confirms my suspicion. If you got us to add Subnet IDs to
> Link-Local addresses, I'm confident you'd next be lobbying them to be
> routeable across different links attached to routers.
> 
> In other words, you'd want these Link-Local addresses to have a scope
> that is greater than a link.
> 
> We used to have an address space for that, called the Site-Local address space.
> 
> Read why they were deprecated and then replaced by ULAs in RFC 3879.
> 
> You won't like that they're easy to type, however that is the cost of
> solving all of the issues described in RFC 3879.
> 
> (If you wanted a problem description of the problems that duplication
> IPv4 address spaces cause i.e. RFC1918 addresses, RFC 3879 would serve
> that purpose too - as does RFC1627 - "Network 10 Considered Harmful
> (Some Practices Shouldn't be Codified)".)
> 
>>> There may be other options that better suit or can be better made to
>>> suit what you're trying to do, such as the work done in the Homenet or
>>> the ANIMA Working Groups.
>>>
>>> Autonomic networking (the focus of ANIMA WG), sounds like it might be
>>> working on solutions to your problem domain.
>>>
>>> "Autonomic networking refers to the self-managing characteristics
>>> (configuration, protection, healing, and optimization) of distributed
>>> network elements, adapting to unpredictable changes while hiding
>>> intrinsic complexity from operators and users."
>>
>> Yes, they should be considered.
>>
>> I will make this suggestion in the IPWAVE WG for the Problem Statement
>> draft.
>>
> 
> Good.
> 
> We really shouldn't have cars that can literally drive themselves,
> while at the same time expecting end users (or anybody) to be spending
> a lot of time typing in literal IP addresses.
> 
> Typing in literal IP addresses is the car equivalent of starting the
> engine with a hand crank at the front bumper. Most cars stopped being
> started that way in the 1920s.
> 
> Regards,
> Mark.
>