Re: [RRG] Consensus? End-user networks need their own portable address space

[Shane Amante <shane@castlepoint.net>]

Noel,

Sorry for the delayed reply.  Please see below.

On Jun 20, 2008, at 10:49 AM, Noel Chiappa wrote:
> > From: "William Herrin" <bill@herrin.us>
>
> > Placing your mail server behind a NAT box ...
> > Placing your VPN concentrator behind a NAT box ...
> > ...
> > Your assertion that NAT resolves the two requirements without PI is
> > proven incorrect.
>
> It's been clear for a long time that use of IPvN addresses outside  
> of a site
> as part of configuration elsewhere, as opposed to using DNS names,  
> introduces
> brittleness into the system.
>
> So what I'm curious about is why people are doing that (using IPvN
> addresses). Is it because there is some perceived robustness or  
> security
> issue with DNS? Or is it something where the fact that IPvN  
> addresses and DNS
> names aren't a 1:1 match is important? Or is it simply because it's  
> 'easier'
> to use IPvN addresses (no need to build in DNS resolution, etc)? (Or  
> all of
> the above, in differing cases?)

IMO, it's largely due the latter, for a few reasons:
1)  Laziness, i.e.: IPvN addresses "just work", (for the most part);
2)  In addition, consider the case where the majority of "network  
equipment" implementations offer administrators no other choice, but  
to use IPvN addresses in, for example, router ACL's, firewalls, NAT  
rules, etc.  For example, consider that there's no 'standard' way to  
define IP prefixes in DNS, which means those devices would have to  
rely on DNS for hostname resolution and 'something else', e.g.:  
something analogous to IRR data, for "name to IP prefix  
resolution" ... therefore, administrators would rather just use IPvN  
addresses and keep it simple.
3)  Finally, there's the robustness (i.e.: avoid creating a circular  
dependency via DNS or other 'ancillary' system) and security concerns,  
which you already mentioned.

One concern, particularly with #2, is if we do an ID/LOC split are we  
punting this 'brittleness' to a higher layer of the stack, i.e.:  
pushing it to the EID layer, since EID's are, for all intents and  
purposes, "permanently" assigned to a site.  Or, is that brittleness  
acceptable/OK?  Said a different (more constructive way), perhaps it  
would be nice to think about fixing "naming" bi-directionally?
1)  Down the stack, from EID to RLOC's;
2)  Up the stack, from EID to: a) "policy enforcement points" (or  
other network infrastructure that's going to do something besides,  
perhaps, forwarding on them), b) "applications", etc.  Or, perhaps  
this is biting off more than we can (or want to) chew?

-shane


> The reason that I ask is that if there's some perceived security/ 
> robustness
> issue in going through a layer of resolution, then won't the same  
> thing
> happen all over again if we change the interpretation of IPvN  
> addresses into
> location-independent identifiers, which have to be mapped into some
> lower-layer thingy which contains information on where the thing  
> actually is?
> Ditto if the mapping from those lower-level thing to IPvN addresses  
> isn't 1:1
> (which would be good for, e.g., multihoming); if the non 1:1 of DNS  
> is an
> issue, would a non 1:1 on identifiers/locators be an issue?
>
> (And as an aside, I would assume any new namespace(s) would not have  
> 1:1
> mappings to existing namespaces, because if a new namespace is just  
> a 1:1
> mapping to an existing one, that greatly limits the power of the new
> namespace. Other than the ability to change the binding over time,  
> the new
> names are inherently basically indentical in properties to the old  
> ones...)
>
>
> > Placing your customer web servers behind a NAT box ...
> > They can't avoid that problem up front with CNAMEs to your DNS  
> > because
> > they often desire the same name that holds the NS and SOA records to
> > reach the web site.
>
> Another place where the architecture has too few namespaces.
> "somecompany.com" is overloaded as i) the website's secondary DNS  
> name (after
> www.somecompany.com), and ii) the NS/SOA name... (at least, if I  
> understood
> your point correctly).
>
> 	Noel
>
>
> --
> 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