Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

[Mark Andrews <[e-mail]>]

Border NAT (IPv4) and depreferencing a prefix + SADR (IPv6) are
equivalent in terms of failure reachability.  Depreferencing a
prefix + SADR (IPv6) just moves the source address selection from
the NAT to the host.  This is what most homes will get to because
there is unlikely to be more than link up/down on the upstream links.

If you add BGP then external reachability can be added to the source
address selection of border NAT.  But if you are up to running BGP
then PI is the way to go.

Extending HE to do multiple source addresses (one per prefix) within
a adddress family will give pretty much the same robustness as
running BGP at the cost of some embryonic connections if the initial
attempt doesn't work.

Mark

In message <[e-mail]>, Ted Lemon writes
:
> On Jun 1, 2014, at 4:38 PM, Ted Lemon <[e-mail]> wrote:
> > On Jun 1, 2014, at 2:02 PM, joel jaeggli <[e-mail]> wrote:
> >> Assumption of the Existence of HE  is a pretty dodgy proposition.
> > Then we can't do multihoming without NAT.
> 
> This rather badly qualified comment appears to have generated a lot of discus
> sion, so to head off further discussion I'd like to clarify a few points.
> 
> First, if you are multihomed, and both paths are working, then a host that do
> es nothing special will work.   Second, if one connection goes out, and the r
> outing updates, then an application that just retries when it doesn't get a c
> onnection will get a connection; for applications for which delays on the ord
> er of the time it takes for routing to update are harmless, redundant multiho
> ming will work with no changes.
> 
> So the statement I made was false when interpreted in this context.   I know 
> that it's false, and you don't need to keep arguing with me to convince me it
> 's false.   I'm sorry for having been sufficiently unspecific that people tho
> ught I meant my statement was true for the above cases.
> 
> The cases I care about are in fact edge cases.   They don't happen all the ti
> me, and depending on the application they may or may not be important.   I ca
> re about them because I've been affected by failures, and I'd like to be able
>  to say how to get these cases right without resorting to the use of NAT or N
> PT.   I'd like for there to be better tools for application developers to use
>  so that they can address these edge cases relatively cheaply; possibly even 
> more cheaply than they now do network programming that doesn't address these 
> edge cases.   If you don't care about these edge cases, you will have little 
> concern for this, and will not consider dealing with these edge cases importa
> nt.
> 
> I, and no doubt most participants on this mailing list, am deeply unintereste
> d in hearing "it works okay for me, so your edge cases don't matter"   I am a
> lso not interested in trying to get you to say "I care deeply about these edg
> e cases."   It's okay with me if you don't care about them, and don't conside
> r it important that they be addressed.   You don't need to respond to this me
> ssage with yet another assertion that there is no problem here--it won't conv
> ince me, and what I want to do about this probably won't affect your applicat
> ion anyway.
> 
> If you are interested in thinking about this problem, the place to discuss it
>  is probably the MIF working group--it's related to the work that's being don
> e there, although it's not the entirety of that work.   If you are not intere
> sted, please let's just let this drop.   I'm sorry for the troll--I didn't in
> tend it to be a troll, but I could have phrased it in a way that was less tro
> llish.  I will try to do better next time.
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]