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

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 26 May 2014 12:36:50 +0000

Hi, All

We're going to update the ULA draft. Before making a new version, I think it would be helpful to confirm/discuss several important topics which were discussed in last IETF meeting. 

I'd like to discuss the topics in different mail threads respectively.
(Current Draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02)
******************************************************************************

#2 Regarding isolated networks

Current draft is a little blurry on what the "isolated" means. Based on former discussion, we'll make it more comprehensive description as the following (just a summary, not the specific revision wording):

- "Temporarily isolated" or "Forever isolated". In general, ULAs fit both cases. Whatever it is temporarily or forever, when administrators need some prefixes to be on-demand and free to use, ULAs are good choice. However, for the temporarily isolated cases, the administrator needs to consider once it gets to connected, the hosts might need to be renumbered; or NAT might be involved if renumbering is not acceptable. If renumbering or NAT for some reason is considered as heavy burden, then the administrators need to carefully consider the adoption of ULAs.

- "Isolated to all networks" or "Isolated to the public Internet". These are two separate scenarios. However, in the perspective of adopting ULAs, there is no essential difference between them. So long as it doesn't connect to the global Internet, ULAs fit them as well. Comparing to other alternatives (an arbitrary GUA, or documentation prefixes), ULAs could provide a lower possibility of collision if they are generated according to the standard method. And the ACL rules for ULAs are much convenient to be set than arbitrary prefixes, to prevent the prefixes leaked if the isolated networks occasionally connected to the global networks. 

Please send your comments. Thanks a lot!

Best regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 May 2014 08:14:38 +1200

> (Current Draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02)

Such networks (which in the IPng design phase we called "dentist's office
networks") are in the class where fully autonomic operation, with
no expert manager, is the normal case. As we observed in 6man, these
networks get automatically renumbered after every power cut. So we
should simply state that renumbering will happen in such networks
whenever necessary. I don't think we should even mention NPTv6.

The two cases are different though. If a network is running with
an ISP prefix and becomes isolated, it is not *forced* to use a
ULA prefix, but it might need to renumber when it gets reconnected
with a different ISP prefix. If it's forever isolated, a ULA would
be appropriate (and fail-safe if it does, in reality, get
connected to an ISP).

> - "Isolated to all networks" or "Isolated to the public Internet". These are two separate scenarios. However, in the perspective of adopting ULAs, there is no essential difference between them. So…

Yes. It seems to me that in "Internet of Things" scenarios, this
would be the normal mode. A group of IoT devices will be connected
to some sort of application-layer gateway, and by using ULA for
that, isolation from other networks is easier to ensure.

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 26 May 2014 14:57:03 -0700 (PDT)

----- Original Message -----
> From: Liubing (Leo) <[email-masked]>
> To: v6ops WG <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Monday, 26 May 2014 10:36 PM
> Subject: [v6ops] ULA draft revision #2 Regarding isolated networks
> 
> Hi, All
> 
> We're going to update the ULA draft. Before making a new version, I think it 
> would be helpful to confirm/discuss several important topics which were 
> discussed in last IETF meeting. 
> 
> (Current Draft link: 
> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02)
> Current draft is a little blurry on what the "isolated" means. Based 
> on former discussion, we'll make it more comprehensive description as the 
> following (just a summary, not the specific revision wording):
> 
> - "Temporarily isolated" or "Forever isolated". In general, 
> ULAs fit both cases. Whatever it is temporarily or forever, when administrators 
> need some prefixes to be on-demand and free to use, ULAs are good choice. 
> However, for the temporarily isolated cases, the administrator needs to consider 
> once it gets to connected, the hosts might need to be renumbered; or NAT might 
> be involved if renumbering is not acceptable. If renumbering or NAT for some 
> reason is considered as heavy burden, then the administrators need to carefully 
> consider the adoption of ULAs.
> 

This paragraph seems to show a fundamental misunderstanding of IPv6's multi-addressing capabilities. IPv6 supports multiple concurrent addresses (from different prefixes), and can learn new ones or deprecate old ones over time. Attachment to a new network doesn't require renumbering, it requires propagating new prefixes for the hosts to use in addition to their existing ones. Primarily RFC6724 address selection will help the hosts choose the right addresses to use as source and destinations when they have multiple addresses.

> - "Isolated to all networks" or "Isolated to the public 
> Internet". These are two separate scenarios. However, in the perspective of 
> adopting ULAs, there is no essential difference between them. So long as it 
> doesn't connect to the global Internet, ULAs fit them as well. Comparing to 
> other alternatives (an arbitrary GUA, or documentation prefixes), ULAs could 
> provide a lower possibility of collision if they are generated according to the 
> standard method. And the ACL rules for ULAs are much convenient to be set than 
> arbitrary prefixes, to prevent the prefixes leaked if the isolated networks 
> occasionally connected to the global networks. 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 May 2014 10:40:15 +1200

Mark,

On 27/05/2014 09:57, Mark ZZZ Smith wrote:
...
> This paragraph seems to show a fundamental misunderstanding of IPv6's multi-addressing capabilities. IPv6 supports multiple concurrent addresses (from different prefixes), and can learn new ones or…

I didn't read it that way. Of course an IPv6 network runs well with
multiple prefixes, which is why overlapped renumbering is possible.

As Fred Baker once pointed out, the real problem is therefore
*numbering* a network (i.e. adding a new prefix, regardless of
whether there are zero or more existing prefixes). The text needs
to be clear about that, for sure.

    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 27 May 2014 01:07:15 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, May 27, 2014 6:40 AM
> To: Mark ZZZ Smith
> Cc: Liubing (Leo); v6ops WG; [email-masked]
> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks
> 
> Mark,
> 
> >> - "Temporarily isolated" or "Forever isolated". In general, ULAs fit
> >> both cases. Whatever it is temporarily or forever, when
> >> administrators need some prefixes to be on-demand and free to use,
> ULAs are good choice.
> >> However, for the temporarily isolated cases, the administrator needs
> >> to consider once it gets to connected, the hosts might need to be
> >> renumbered; or NAT might be involved if renumbering is not
> >> acceptable. If renumbering or NAT for some reason is considered as
> >> heavy burden, then the administrators need to carefully consider the
> adoption of ULAs.
> >>
> >
> > This paragraph seems to show a fundamental misunderstanding of IPv6's
> multi-addressing capabilities. IPv6 supports multiple concurrent addresses
> (from different prefixes), and can learn new ones or deprecate old ones over
> time. Attachment to a new network doesn't require renumbering, it requires
> propagating new prefixes for the hosts to use in addition to their existing
> ones. Primarily RFC6724 address selection will help the hosts choose the
> right addresses to use as source and destinations when they have multiple
> addresses.
> 
> I didn't read it that way. Of course an IPv6 network runs well with multiple
> prefixes, which is why overlapped renumbering is possible.
> 
> *numbering* a network (i.e. adding a new prefix, regardless of whether
> there are zero or more existing prefixes). The text needs to be clear about
> that, for sure.

[Bing] Yes. I considered *numbering a new prefix* as a special kind of *renumbering* in the above texts. I need to make it clear. ULA+GUA is a recommended (we won't use the word in the new version) use case in the current draft. What I need to emphasize should be: the administrators need to consider the operational burden of numbering a new prefix and ensuring the RFC6724 address selection if the isolated network gets connected in the future.

Regards,
Bing

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 May 2014 11:33:51 +0900

> - "Temporarily isolated" or "Forever"

we long ago concluded that today's isolated network will most likely be
connected some day.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 May 2014 15:03:12 +1200

> we long ago concluded that today's isolated network will most likely be

Exactly why I said "If it's forever isolated, a ULA would
be appropriate (and fail-safe if it does, in reality, get
connected to an ISP)."

In fact, I should have said: If it's forever isolated, a ULA would
be appropriate (and fail-safe if it does, in reality, get
connected to an ISP or another "isolated" network).

  Brian

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 May 2014 12:06:22 +0900

>> we long ago concluded that today's isolated network will most likely
>> be connected some day.
> 

not really.  my point is that it has been proven to be unsafe to assume
that any network will be forever isolated.

randy

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 May 2014 23:22:59 -0400

> that any network will be forever isolated.

Oh.   You utterly failed to make that clear.   Not that it matters, since the whole point of ULAs is to address that concern.   You might argue that they fail to do so, but you did not.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 May 2014 13:23:48 +1000

> that any network will be forever isolated.

You are both saying that networks that are notionally isolated tend to
get connected.  There is no "assumsion that networks will remain isolated
forever". 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 27 May 2014 03:25:24 +0000

Hi Randy,

> > In fact, I should have said: If it's forever isolated, a ULA would be
> > appropriate (and fail-safe if it does, in reality, get connected to an
> > ISP or another "isolated" network).
> 
> not really.  my point is that it has been proven to be unsafe to assume that
> any network will be forever isolated.
[Bing] Whatever it is *forever* or not, during the period when it is isolated, ULAs are reasonable choice. Only if the operational burden of adding a global prefix and ensuring the RFC6724 address selection would be not acceptable when the network connects globally in the future, there might be problem of using ULAs.

Regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 May 2014 15:31:47 +1200

> that any network will be forever isolated.

I really think we're agreeing. The only safe assumption is
that a "forever isolated" network will be connected at some
time in the future. Even if it only happens one time in a
hundred, we have to assume it.

If you unexpectedly connect two Net 10s together bad things
will happen. If you unexpectedly connect ULA1 and ULA2
together, less bad things will happen.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 May 2014 12:35:51 +0900

>If you unexpectedly connect ULA1 and ULA2 together, less bad things
> will happen.

s/will/might not/

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 May 2014 12:51:13 +0900

> hundred, we have to assume it.

OK, we agree that "forever isolated" just means "will be connected in the
future". But if we agree on that, then we must accept that "forever
isolated" is no different from "temporarily isolated". Therefore:

1. There is only one case - "temporarily isolated".
2. We should not design for "forever isolated", since it does not exist.

Agreed?

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 May 2014 13:13:00 +0900

> 2. We should not design for "forever isolated", since it does not

damn!  houston, we have found a clueon!

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 May 2014 13:23:29 +0900

> damn!  houston, we have found a clueon!

Just wanted to put that down in writing very clearly. If everyone agrees
with it, then great - call me an idiot for stating the obvious. If people
don't agree with it, then better to find that out sooner rather than later.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 27 May 2014 05:09:02 +0000

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, May 27, 2014 12:23 PM
To: Randy Bush
Cc: v6ops WG
Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks

Just wanted to put that down in writing very clearly. If everyone agrees with it, then great - call me an idiot for stating the obvious. If people don't agree with it, then better to find that out sooner rather than later.
[Bing] Hi Lorenzo & all,
How about writing it this way:
- Don’t specifically divide the cases into “temporarily” and “forever” in the draft.
- Just say, now you have an isolated network, ULAs are reasonable choice, because it is free and can be used right away.
- But there are some considerations if the network is connected someday:
   * If it connects to another isolated/private network, then comes the collision problem. However, if the ULAs were generated by the standard way, this won’t be a big problem.
  * If it connects to the global Internet, then need some operation to add a new global prefix and ensure the address selection in the right form. Or just put a NAT.
- If these further operations/considerations are unacceptable for some reasons, then the administrators need to be careful with using ULAs in current isolated networks.

Do you agree?

Regards,
Bing

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 May 2014 14:22:06 +0900

> - But there are some considerations if the network is connected

no.

in front, state very clearly that you may think you have an isolated
network now but the wisdom of the internet is that it is unlikely to
stay isolated forever no matter what you think today.

> - Just say, now you have an isolated network, ULAs are reasonable
>   choice, because it is free and can be used right away. 

and because you can not assume it will remain isolated, if you are silly
enough to use a ULA today, you had best plan to change that.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 May 2014 14:26:40 +0900

On Tue, May 27, 2014 at 2:09 PM, Liubing (Leo) <[email-masked]>wrote:
>
>   * If it connects to the global Internet, then need some operation to add
> a new global prefix and ensure the address selection in the right form. Or
> just put a NAT.
>

Please don't propose NAT as a solution to this.

   - NAT imposes substantial additional complexity on many applications,
   and breaks applications that do not implement that complexity.
   - NAT is strongly discouraged by the IAB (RFC 5902 section 4.1).
   - NAT provides no advantages compared to using ULA + GUA.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 May 2014 16:04:17 +1000

In message <[email-masked]>, Randy Bush writes:
> > - Dont specifically divide the cases into temporarily and forever
> >   in the draft. 

Using ULA does not preclude using a GUA as well.  ULA doesn't
preclude using a second ULA prefix.

You seem to assume that you will need renumber/remove the existing
ULA addresses.  For all practical senarios you will never need to
do this.  Even if two or more sites using the same ULA prefix connect
you just add additional ULA prefixes to communicate.  The old ULA
addresses are not used for inter site communication.

Mark

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 May 2014 08:49:37 +0200 (CEST)

On Tue, 27 May 2014, Mark Andrews wrote:

> You seem to assume that you will need renumber/remove the existing ULA 
> addresses.  For all practical senarios you will never need to do this. 
> Even if two or more sites using the same ULA prefix connect you just add 
> additional ULA prefixes to communicate.  The old ULA addresses are not 
> used for inter site communication.

That means that all resources that needs to be accessed from one 
organizaton to the next uses this new common ULA in order for source 
address selection to work properly. Only way to solve this that I can see 
it to use split horizon DNS, which is yet another mess operationally, in 
addition that all the new services addresses will need to be configured in 
firewalls etc.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 May 2014 16:54:41 +1000

In message <[email-masked]>, Mikael Abrah
> addition that all the new services addresses will need to be configured in 

You need split horizon if you use ULA regardless of whether you
connect to another ULA site or not.  ULA + GUA requires split
horizon.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 May 2014 09:05:03 +0200 (CEST)

On Tue, 27 May 2014, Mark Andrews wrote:

> You need split horizon if you use ULA regardless of whether you connect 
> to another ULA site or not.  ULA + GUA requires split horizon.

Well, if that's the methodology then you now have 3 prefixes so it's an 
additional split horizon to maintain.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 27 May 2014 08:12:44 +0000

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, May 27, 2014 1:27 PM
To: Liubing (Leo)
Cc: Randy Bush; v6ops WG
Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks

On Tue, May 27, 2014 at 2:09 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
  * If it connects to the global Internet, then need some operation to add a new global prefix and ensure the address selection in the right form. Or just put a NAT.

  *   NAT imposes substantial additional complexity on many applications, and breaks applications that do not implement that complexity.
  *   NAT is strongly discouraged by the IAB (RFC 5902 section 4.1).
  *   NAT provides no advantages compared to using ULA + GUA.
[Bing] Ok, I shouldn’t mention it. Thanks.

Regards,
Bing

---

From: Owen DeLong <[email-masked]>
Date: Tue, 27 May 2014 01:49:07 -0700

On May 26, 2014, at 10:26 PM, Lorenzo Colitti <[email-masked]> wrote:

> On Tue, May 27, 2014 at 2:09 PM, Liubing (Leo) <[email-masked]> wrote:
> NAT imposes substantial additional complexity on many applications, and breaks applications that do not implement that complexity.
> NAT is strongly discouraged by the IAB (RFC 5902 section 4.1).
> NAT provides no advantages compared to using ULA + GUA.

+1

NAT in all its forms, including NPT should be avoided wherever possible.

We certainly should not be endorsing in  in WG output or RFCs.

Owen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 May 2014 11:24:28 +0200

In your letter dated Tue, 27 May 2014 14:22:06 +0900 you wrote:
> and because you can not assume it will remain isolated, if you are
> silly enough to use a ULA today, you had best plan to change that.

In most markets, a 'dentist office' that has an Internet connection and switches
ISPs will get a new prefix.

This is problem that need to be solved anyhow.

So if we can migrate a small business from one prefix to another, we can just as well
do that from ULA to GUA.

I don't see why we would need to discuss the foreverness of ULA, when GUAs are not
at all forever. 

(I naively assume that having all small businesses get a PI prefix is not going to
happen)

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 May 2014 11:31:10 +0200

>additional split horizon to maintain.

I always assumed that connecting two ULA prefixes just involved setting up
routing between them. So each host would just get one ULA prefix.

With split horizon you would have to do something to make sure that DNS requests
get routed properly.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 08:52:02 -0400

> I don't see why we would need to discuss the foreverness of ULA, when GUAs are not

You'd like to think that, and in some circumstances it makes sense.   If my homenet has a ULA, it has it so that local communications can proceed when I don't have an internet connection.   A renumbering event that switches to a new ULA shouldn't be a big deal.

The operational situation that's problematic is the large enterprise scenario, where you have two large enterprises with their own ULAs that merge.   If those ULAs happen to clash, you have to renumber at least one of them.   If they don't clash, you still have to deal with routing them (although I think the split-horizon complexity objection Mikael raised ought to be thought through carefully before being asserted as factual, because I think it can be addressed through routing and not naming).

I wish people wouldn't say "that is evil and must be burned" because it's clearly useful in some real scenarios where there is no better alternative, and hence I think documenting those scenarios and explaining how to do them right (IOW, not wind up with NAT) is a valuable service we can do for the community, which will use them regardless.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 27 May 2014 14:30:34 +0100

On 27/05/2014 13:52, Ted Lemon wrote:
> If those ULAs happen to clash, you have to renumber at least one of them.

or use NAT.  I'm not saying this in order to throw fuel on an existing
fire, but simply because this is the reality for many organisations in the
ipv4 world, and I see little reason why it will change for ipv6.  The IETF
can make recommendations about whether it thinks this is a good idea or
not, but it is not productive to pretend that the elephant isn't in the room.

Nick

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 27 May 2014 13:35:22 +0000

And what's next ?  Stop path MTU discovery support ?  Allow Fragmentation again ?  Anything else ?
If we start mimic IPv4 fully, we're really going the wrong way .... (my personal opinion of course)

Regs
Carl

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: dinsdag 27 mei 2014 15:31
To: Ted Lemon; Philip Homburg
Cc: v6ops WG
Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks

> If those ULAs happen to clash, you have to renumber at least one of them.

or use NAT.  I'm not saying this in order to throw fuel on an existing fire, but simply because this is the reality for many organisations in the
ipv4 world, and I see little reason why it will change for ipv6.  The IETF can make recommendations about whether it thinks this is a good idea or not, but it is not productive to pretend that the elephant isn't in the room.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 27 May 2014 14:51:56 +0100

> personal opinion of course)

if you feel that NAT may have drawbacks which makes it a less appropriate
choice than renumbering, then feel free to suggest some wording for the draft.

Ignoring the existence of NAT will not make it go away.  Educating people
on its limitations may lessen its deployment, maybe.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 May 2014 15:56:36 +0200

In your letter dated Tue, 27 May 2014 08:52:02 -0400 you wrote:
>The operational situation that's problematic is the large enterprise 
>scenario, where you have two large enterprises with their own ULAs that 
>merge.   If those ULAs happen to clash, you have to renumber at least 
>one of them.   If they don't clash, you still have to deal with routing 
>them (although I think the split-horizon complexity objection Mikael 
>raised ought to be thought through carefully before being asserted as 
>factual, because I think it can be addressed through routing and not 
>naming).

If you are a large entrprise, just spend the 50 euro or so (RIPE service region) it
costs to get your own prefix.

I assume that any large enterprise is very likely to be multi-homed anyhow. Even
becoming an LIR should not even be noticable in the budget.

No real reason for a large enterprise to use ULA.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 09:59:51 -0400

> not, but it is not productive to pretend that the elephant isn't in the room.

Right, the point is that if we provide advice on how to set up ULA networks so that future transitions of this sort do not require NAT, that's worth doing.   Actually, for the enterprise scenario, I think the advice should just be "get a GUA, use it like a ULA" because that excludes the possibility of a future clash when two behemoths merge.   But it makes source address selection harder.   And there was a document a while back about informal ULA registries, IIRC, which could also represent a good mitigation strategy if it were to happen (but I think that's outside our scope of work).

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 27 May 2014 13:57:28 +0000

Well, lately, it seems more and more the case that NAT can solve all problems, which I don't think will do.
Education indeed will help and there's no magic, but dragging NAT along each time is not helping either.

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: dinsdag 27 mei 2014 15:52
To: Wuyts Carl; Ted Lemon; Philip Homburg
Cc: v6ops WG
Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks

> (my personal opinion of course)

if you feel that NAT may have drawbacks which makes it a less appropriate choice than renumbering, then feel free to suggest some wording for the draft.

Ignoring the existence of NAT will not make it go away.  Educating people on its limitations may lessen its deployment, maybe.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 10:08:48 -0400

> costs to get your own prefix.

Yes, but do we tell them to do that?   Do we tell them how to make it work?   Do we tell them how to make source address selection do the right thing?  ULAs have a nice feature that GUAs don't: your stack won't choose a ULA as a source when the destination is a GUA.   If they get a GUA from RIPE, they lose that feature.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 27 May 2014 15:19:30 +0100

On 27/05/2014 14:59, Ted Lemon wrote:
> Right, the point is that if we provide advice on how to set up ULA
> networks so that future transitions of this sort do not require NAT,
> that's worth doing. 

sounds good to me.

> Actually, for the enterprise scenario, I think the
> advice should just be "get a GUA, use it like a ULA" because that
> excludes the possibility of a future clash when two behemoths merge.
> But it makes source address selection harder.   And there was a document
> a while back about informal ULA registries, IIRC, which could also
> represent a good mitigation strategy if it were to happen (but I think
> that's outside our scope of work).

register or do not register.  there is no "informal".

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 10:21:48 -0400

> register or do not register.  there is no "informal".

It depends on whether you want certainty or mitigation.   I don't think we can have certainty with ULAs.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 27 May 2014 16:26:17 +0200

Hi Ted,

> Yes, but do we tell them to do that?   Do we tell them how to make it work?   Do we tell them how to make source address selection do the right thing?  ULAs have a nice feature that GUAs don't: you…

I know one big enterprise that uses ULA for certain networks for exactly that reason. They have networks that are by security policy not allowed to have any direct layer-3 connection to the outside world. All such communication must go through layer-7 gateways/proxies. Using ULA for such high-security-zones makes the source address selection simpler for the devices on its border, like the proxy servers. All other networks use the RIPE-assigned /48.

Cheers,
Sander

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 May 2014 16:30:45 +0200

In your letter dated Tue, 27 May 2014 10:08:48 -0400 you wrote:
>Yes, but do we tell them to do that?   Do we tell them how to make it work?   Do we te
>ll them how to make source address selection do the right thing?  ULAs have a nice fea
>ture that GUAs don't: your stack won't choose a ULA as a source when the destination i
>s a GUA.   If they get a GUA from RIPE, they lose that feature.

At the moment, I would not advice anyone to use more than one prefix at the same
time. It can be made to work, but the operational complexity is high.

I didn't keep track. Are GUAs now considered out of scope for ULAs?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 10:37:28 -0400

> time. It can be made to work, but the operational complexity is high.

ULAs give you a lot of complexity reduction for free.   I tend to agree that multiple prefixes are hard, but this is a problem we need to solve.

> I didn't keep track. Are GUAs now considered out of scope for ULAs?

Yes.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 May 2014 16:51:34 +0200

>> I didn't keep track. Are GUAs now considered out of scope for ULAs?

Hmm. What RFC changed that? I looked at RFC-6724, but that still considers ULAs as
a special case of global scope. (Section 3.1 "Also, note that ULAs are considered as
global, not site-local, [...]")

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 11:01:13 -0400

> global, not site-local, [...]")

Read section 10.   I'm not sure if/where there's a clear normative requirement that ULAs be treated as less preferable than GUAs, but they are definitely treated that way by stacks I've used.   I have a ULA configured on my home network, and none of the IPv6-capable devices in the home have trouble getting out to the internet.

ULAs are global in scope in the sense that they are (notionally) unique across the internet, but not in the sense that they are globally reachable.

---

From: Tim Chown <[email-masked]>
Date: Tue, 27 May 2014 16:19:31 +0100

> Right, the point is that if we provide advice on how to set up ULA networks so that future transitions of this sort do not require NAT, that's worth doing.   Actually, for the enterprise scenario,…

The enterprise IPv6 incremental deployment text is just going up for publication, see http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-05.
That pretty much captures what Ted says, but also points to the draft under discussion here.  See section 2.6 in particular.

Tim

---

From: Sander Steffann <[email-masked]>
Date: Tue, 27 May 2014 17:22:56 +0200

Hi Philip,

> global, not site-local, [...]")

They are still considered to be in the global scope. Section 3.1 of that RFC is indeed very clear on that. They have a specific precedence and label, but are considered to be in the global scope.

Cheers,
Sander

---

From: Tim Chown <[email-masked]>
Date: Tue, 27 May 2014 16:27:59 +0100

> Read section 10.   I'm not sure if/where there's a clear normative requirement that ULAs be treated as less preferable than GUAs, but they are definitely treated that way by stacks I've used.   I h…

As you say Ted, RFC6724 observes the scope of ULAs being what it is, but in the part Philip quotes the rest of the sentence replacing the “…” reads “... but are handled via the prefix policy table as discussed in Section 10.6.)”   Any system that is 6724-compliant should prefer globals over ULAs, unless the policy table has been modified. This issue was discussed in some depth in homenet.

> ULAs are global in scope in the sense that they are (notionally) unique across the internet, but not in the sense that they are globally reachable.

Perhaps (probabilistically) rathr than (notionally).

Tim

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 May 2014 17:28:05 +0200

In your letter dated Tue, 27 May 2014 17:22:56 +0200 you wrote:
>Hi Philip,
>
>> Hmm. What RFC changed that? I looked at RFC-6724, but that still =
>considers ULAs as
>> a special case of global scope. (Section 3.1 "Also, note that ULAs are =
>considered as
>They are still considered to be in the global scope. Section 3.1 of that 
>RFC is indeed very clear on that. They have a specific precedence and 
>label, but are considered to be in the global scope.

I guess longest prefix matching would in practice already take care of the
precedence/label difference. But I noticed that longest prefix matching is only
adviced.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 27 May 2014 11:54:09 -0700

> Yes, but do we tell them to do that?   Do we tell them how to make it work?   Do we tell them how to make source address selection do the right thing?  ULAs have a nice feature that GUAs don't: you…

If they get GUA from RIPE, they don’t need that feature, as there aren’t multiple source addresses to choose from.

You’re not making much sense here, Ted.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 15:04:54 -0400

> You’re not making much sense here, Ted.

If they can get it routed, you are correct.   But we are not assuming that they can, and even if they can, it will probably be costly.   So in practice we can expect them to use that GUA as if it were a ULA, and then they need to use source address selection to ensure that it is only used internally.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 27 May 2014 12:11:03 -0700

> If they can get it routed, you are correct.   But we are not assuming that they can, and even if they can, it will probably be costly.   So in practice we can expect them to use that GUA as if it w…

In my experience, it is quite easy and not particularly costly to get a /48 routed. Do you have different experience?

Owen
AS 1734
2620:0:930::/48
routed from my home.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 15:18:15 -0400

> In my experience, it is quite easy and not particularly costly to get a /48 routed. Do you have different experience?

I'm just a poor bastard with a home connection that now (thanks, Comcast!) has native IPv6.   If you tell me that every enterprise on the planet can easily get a /48 routed at no cost, then indeed that's probably the right way to go.   I will defer to others with more experience in these matters to tell me whether or not that is so; my understanding hitherto has been that it is not.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 May 2014 08:17:08 +1000

> costs to get your own prefix.
 
A /56 is over AUD1180 (+10% GST) annually.  Thanks for playing.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 27 May 2014 22:22:19 +0000

> I'm just a poor bastard with a home connection that now (thanks, Comcast!) has native IPv6.   If you tell me that every enterprise on the planet can easily get a /48 routed at no cost, then indeed…

Speaking for myself, identifying every residence on a residential network as a reasonable target for PI prefix assignment sounds like a great reason to dramatically increase the cost to a network that presents a PI prefix, for scaling reasons.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 May 2014 08:23:13 +1000

> If we start mimic IPv4 fully, we're really going the wrong way .... (my personal opinion of course)

Please state clearly the RFC which disallows fragmentation?
Hint: There isn't one.

Fragmentation is a BASIC part of IPv6.  It is done in the sending
host rather than in the core of the network but it is DONE!!!!!
 
> ipv4 world, and I see little reason why it will change for ipv6.  The IETF can make recommendations about whether it t
> hinks this is a good idea or not, but it is not productive to pretend that the elephant isn't in the room.
> 
> Nick
>

---

From: joel jaeggli <[email-masked]>
Date: Tue, 27 May 2014 15:31:18 -0700

> Please state clearly the RFC which disallows fragmentation?

you know he's referring to intermediate fragmentation...

http://tools.ietf.org/html/rfc2460#section-5

> host rather than in the core of the network but it is DONE!!!!!

yes.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 27 May 2014 15:37:43 -0700 (PDT)

Hi Brian,

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>
> Cc: Liubing (Leo) <[email-masked]>; v6ops WG <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tuesday, 27 May 2014 8:40 AM
> multi-addressing capabilities. IPv6 supports multiple concurrent addresses (from 
> different prefixes), and can learn new ones or deprecate old ones over time. 
> Attachment to a new network doesn't require renumbering, it requires 
> ones. Primarily RFC6724 address selection will help the hosts choose the right 
> addresses to use as source and destinations when they have multiple addresses.
> 

I think there are a number of reasons I read it that way.

Firstly, to me, the word 'renumber' reads as 'replace the numbers', so renumbering a network involves just that - removing the old numbers and adding new ones. The suggestion of using NAT has been in IPv4 the alternative to 'replacing the numbers', so suggesting that for IPv6 seemed to further support the misunderstanding of IPv6's ability to support multiple concurrent addresses/prefixes/spaces.

The other reason is that I've actually seen a residential CPE try to swap between global addresses and ULAs. I deal with a number of residential IPv6 CPE vendors in around 2009, and one of them had attempted to support ULAs, but had not done a good job of it. When the global prefix went away because the WAN link failed, the CPE would try to both flush the global prefix by setting a 0 valid liftime (or similar, I can't quite recall) and replace it with a ULA in the RAs on the LAN side. When the WAN link came back, it tried to do the opposite. When I provided feedback to this vendor on this issue and others related to their IPv6 implementation, they just ignored it, unlike the other CPE vendors I was dealing with.

Regards,
Mark.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 May 2014 08:41:10 +1000

In message <[email-masked]>, joel jaeggli writes:
> >=20
> > In message <[email-masked]=
> lti.com>, Wuyts Carl writes:
> >> And what's next ?  Stop path MTU discovery support ?  Allow Fragmentat=
> ion again ?  Anything else ?
> >> If we start mimic IPv4 fully, we're really going the wrong way .... (m=
> y personal opinion of course)
> >=20

Except it isn't clear that that is what he is referring to.  I've
seen too many people assume that fragmentation no longer exists,
period.

"Allow router to fragment again" would be much clearer.

As for MTU discovery support I really wish we could get POSIXs to
pick up the Advanced Socket API as it is the part with the fragmention
controls in it which are needed by nameservers.

> >> From: v6ops [mailto:[email-masked]] On Behalf Of Nick Hilliard=
> 
> >> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks=
> 
> >>
> >>> If those ULAs happen to clash, you have to renumber at least one of t=
> hem.
> >>
> >> or use NAT.  I'm not saying this in order to throw fuel on an existing=
> >> ipv4 world, and I see little reason why it will change for ipv6.  The =
> IETF can make recommendations about whether it t
> >> hinks this is a good idea or not, but it is not productive to pretend =
> that the elephant isn't in the room.
> >>
> >> Nick
> >>
> --VuCKSKMJMcusWKUlpsUBcXRvkXr8liNU3
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEARECAAYFAlOFEjYACgkQ8AA1q7Z/VrKOJACdH35TP3o3jZ7BH8FsYvDlLe8F
> g3wAn3Dxl4l1lPGAv51OW3/Ht8Mnx/nS
> =/bYT
> -----END PGP SIGNATURE-----
> 
> --VuCKSKMJMcusWKUlpsUBcXRvkXr8liNU3--

---

From: Randy Bush <[email-masked]>
Date: Wed, 28 May 2014 11:32:37 +0900

> fire, but simply because this is the reality for many organisations in
> the ipv4 world, and I see little reason why it will change for ipv6.
> The IETF can make recommendations about whether it thinks this is a
> good idea or not, but it is not productive to pretend that the
> elephant isn't in the room.

so, bottom line here is, in its inimitable fashion, the ietf will push
ULA and get NAT.  what a win!

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 May 2014 14:33:39 +1200

Hi Mark,

> Firstly, to me, the word 'renumber' reads as 'replace the numbers', so renumbering a network involves just that - removing the old numbers and adding new ones. The suggestion of using NAT has been…

Whereas in RFC 4192 it means exactly the opposite: adding new numbers and
then removing the old ones. That really is a change in thinking for IPv6
and of course you are right - multi-addressing is not understood in the
industry.

> The other reason is that I've actually seen a residential CPE try to swap between global addresses and ULAs. I deal with a number of residential IPv6 CPE vendors in around 2009, and one of them had…

That's horrible. It doesn't conform to RFC 7084 either, which clearly
states that "prefix(es) (and ULA prefix if configured...)" must
be advertised.

    Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 May 2014 14:48:39 +1200

> I know one big enterprise that uses ULA for certain networks for exactly that reason. They have networks that are by security policy not allowed to have any direct layer-3 connection to the outside…

Exactly. This was always one of the expected use cases for ULAs. Some
people think it's a bad idea, but some corporate security policies will
prefer this, and it isn't for the IETF ivory tower to tell them not to.

The nature of ULAs makes it easier to talk them out of NAT, though,
which is absolutely not the case for RFC 1918 addresses. (If we say
anything about NATs in this draft, it should be to say that since
ULAs are guaranteed* not to clash, and can co-exist with routeable
GUAs, NAT is always unnecessary.)

*i.e., guaranteed to very high probability if correctly generated.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 May 2014 15:00:00 +1200

> I'm just a poor bastard with a home connection that now (thanks, Comcast!) has native IPv6.   If you tell me that every enterprise on the planet can easily get a /48 routed at no cost, then indeed…

Let's assume a paltry 5 billion homenets, each with a routed /48.

Well, today BGP-4 has 17687 entries for IPv6, according to
http://bgp.potaroo.net/v6/as2.0/index.html
It will be interesting when that number changes to 5000000000.

Somehow I doubt this will happen. Quite how far we go in that
direction is an interesting question.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 May 2014 15:04:15 +1200

>> host rather than in the core of the network but it is DONE!!!!!

But see http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop
for a dose of reality.

   Brian

> ------------------------------------------------------------------------
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 28 May 2014 12:11:51 +0900

> *i.e., guaranteed to very high probability if correctly generated.

can we return to the real world?  you have seen the distribution of
the ULAs that were leaked.  wanna guess at the ones that were not
leaked?

do not design specs that work only when standing on your left foot
and holding your right ear.  design them to work when chaos reigns
and the rack and stack folk are working at three in the morning.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 28 May 2014 12:12:27 +0900

> direction is an interesting question.

You don't need ULA to solve this. homenet is solving this problem using
source+destination routing.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 28 May 2014 03:13:22 +0000

> From: v6ops [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: Tuesday, May 27, 2014 10:09 PM
> To: Philip Homburg
> Cc: v6ops WG
> > If you are a large entrprise, just spend the 50 euro or so (RIPE
> > service region) it costs to get your own prefix.
> 
> Yes, but do we tell them to do that?   Do we tell them how to make it work?
> Do we tell them how to make source address selection do the right thing?
> ULAs have a nice feature that GUAs don't: your stack won't choose a ULA as
> a source when the destination is a GUA.   If they get a GUA from RIPE, they
> lose that feature.
[Bing] This is a very good point. In current draft, we proposed to use ULA+GUA for separated local and global communication, and pointed out the address selection issue. But we didn't make an explicit comparison that "ULA+GUA" prefers "GUA1+GUA2" because of the address selection policy.
We'll add some description of it. Thanks Ted for pointing it out.

Regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 May 2014 16:24:59 +1200

> and the rack and stack folk are working at three in the morning.

I understand the problem. Users are idiots, including us when we
act as users. I am not arguing that ULAs will prevent all operational
problems caused by private addressing. I am only arguing that there will
be private addressing and that ULAs will cause fewer problems than
RFC1918-for-IPv6 would.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 May 2014 16:29:28 +1200

> source+destination routing.

Indeed, and not just homenet. I just wanted to remind people that prefix-per-site
has a scaling issue. That's why I changed the Subject:.

On the other hand, and I speak from experience, persuading IT departments
to support SADR is harder than persuading them to allow multiple prefixes.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 May 2014 14:39:10 +1000

> to support SADR is harder than persuading them to allow multiple prefixes.

Given SADR normally implies multiple prefixes it stands to reason.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 28 May 2014 07:08:16 +0200 (CEST)

On Tue, 27 May 2014, Ted Lemon wrote:

> I'm just a poor bastard with a home connection that now (thanks, 
> Comcast!) has native IPv6.  If you tell me that every enterprise on the 
> planet can easily get a /48 routed at no cost, then indeed that's 
> probably the right way to go.  I will defer to others with more 
> experience in these matters to tell me whether or not that is so; my 
> understanding hitherto has been that it is not.

We should spend more time on getting renumbering working properly. Having 
all Enterprise get PI space will make the routing system melt down.

---

From: Doug Barton <[email-masked]>
Date: Tue, 27 May 2014 22:37:50 -0700

On 05/27/2014 07:32 PM, Randy Bush wrote:
> ULA and get NAT.

Randy,

We have a substantial number of medium-sized enterprises which share the 
following characteristics:

1. They are large enough to have some internal resources that need 
addressing (printers, file servers, maybe a web site or two)

2. They are small enough that PI space and their own ASN are not practical

3. Some of them want to have multiple service providers, either for 
failover or traffic shaping

4. They don't want to have to renumber all of their internal resources 
when they change providers

What's your solution for them?

Doug

---

From: Doug Barton <[email-masked]>
Date: Tue, 27 May 2014 22:39:39 -0700

Mark,

How does this help the medium-sized enterprise which has internal 
resources that need host names?

Doug

---

From: Doug Barton <[email-masked]>
Date: Tue, 27 May 2014 22:41:15 -0700

On 05/27/2014 06:35 AM, Wuyts Carl wrote:
> If we start mimic IPv4 fully, we're really going the wrong way ....

Argumentum ad absurdum

---

From: [email-masked]
Date: Wed, 28 May 2014 08:49:37 +0200 (CEST)

> ULA and get NAT.  what a win!

IPv6 will get NAT no matter what the IETF does. Trying to reduce the
damage from NAT, for instance by having sensible rules for ULA, seems
like a good thing.

Steinar Haug, AS2116

---

From: Owen DeLong <[email-masked]>
Date: Wed, 28 May 2014 00:59:46 -0700

On May 27, 2014, at 8:00 PM, Brian E Carpenter <[email-masked]> wrote:

> Let’s assume a paltry 5 billion homenets, each with a routed /48.

That’s a pretty absurd number.

There are roughly 7.1 billion people on the planet. The average household size in the us is 3.4 people. In most countries, it tends to be somewhat larger. By my calculation, 7.1/3 is a little less than 2.4, nowhere near 5.

> It will be interesting when that number changes to 5000000000.

Yes, BGP4 has a limited future and we need to find a better way to do routing. This is not news. However, in reality, this would only apply to the subset of households that feel they cannot easily renumber and choose to pay RIR and other fees to enable the use of a portable prefix.

> direction is an interesting question.

Yep.

Owen

---

From: Philip Homburg <[email-masked]>
Date: Wed, 28 May 2014 10:09:42 +0200

>be private addressing and that ULAs will cause fewer problems than

Maybe we can keep a bit of context around what scenario we are talking about.

Say:
1) Small organisation, doesn't get PI space, has to renumber when moving to a different
   ISP. The IPv4 solution is to use NAT. Maybe we can do better for IPv6. Probably
   collisions of ULA space during a merger are not a big deal.
2) Bigger organisation, does have PI space and has a more or less homogenous network.
   No real need for ULA.
3) Big organisation, wants to have a secret network that only communicates through
   application layer gateways. Should be able to pick a proper ULA if they need one.
   Otherwise, though luck. No real need for ULA. It may make source address selection
   a bit easier, but that is only a small part of the puzzle.

I think the only interesting case is 1). Whether or not we make renumbering easy enough
that they don't do NAT is an open question. A large part of that is in software
configuration: is it possible to store the current prefix in such a way that software
can easily pick it up.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 28 May 2014 01:16:56 -0700

> A /56 is over AUD1180 (+10% GST) annually.  Thanks for playing.

Yes, APNIC now has the distinction of being the absolutely most expensive RIR on the planet.

However, outside of the APNIC region, prices are much more reasonable.

US 100 per resource (regardless of size) ARIN
EU  50 (flat rate, regardless of resources) RIPE
US 600 (up to a /35) LACNIC
US 100 (per /48?) AfriNIC
AU1180 (/56, logarithmic formula for larger blocks) APNIC

So, it looks like at a little less than twice your next closest competitor, APNIC is the clear winner for the highest prices.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 28 May 2014 01:22:48 -0700

> be private addressing and that ULAs will cause fewer problems than

I agree, but that’s rather like an argument that the common cold causes less severe symptoms than small pox.

Owen

---

From: Tore Anderson <[email-masked]>
Date: Wed, 28 May 2014 11:21:27 +0200

* Doug Barton

> 2. They are small enough that PI space and their own ASN are not practical

You don't need an ASN to use PI space.

> What's your solution for them?

We have a few customers in the same situation. So we obtained a PI
prefix for them, which costs next to nothing in the RIPE region at
least, and advertise the prefix on their behalf (and in the cases where
there's a second upstream, the second upstream does the same). Works
perfectly well, and is much less complex than anything solution
involving ULA, NAT, multiple prefixes on the hosts, or whatever. The
customer just gets a bunch of addresses he can use in perpetuity.

Tore,
who prefers to KISS

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 May 2014 10:27:56 +0100

> But see http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop

Tests that Fernando and I reported at the last IEPG show around 50% of the Alexa top 1m sites which support IPv6 also drop frags.  Tests for other types of EH are far from encouraging too.

Tim

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 28 May 2014 09:25:49 +0000

+1 for PI usage, however, seems some have difficulties getting it, as you need to be RIPE (or other region) member (not free-of-charge) to get one and an ISP is not always really "happy" to do this (as they become a little more independent)

Carl 

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Tore Anderson
Sent: woensdag 28 mei 2014 11:21
To: Doug Barton; Randy Bush
Cc: V6 Ops List
Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks

* Doug Barton

> We have a substantial number of medium-sized enterprises which share 
> the following characteristics:
> 

> What's your solution for them?

We have a few customers in the same situation. So we obtained a PI prefix for them, which costs next to nothing in the RIPE region at least, and advertise the prefix on their behalf (and in the cases where there's a second upstream, the second upstream does the same). Works perfectly well, and is much less complex than anything solution involving ULA, NAT, multiple prefixes on the hosts, or whatever. The customer just gets a bunch of addresses he can use in perpetuity.

Tore,
who prefers to KISS

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 May 2014 10:50:53 +0100

> configuration: is it possible to store the current prefix in such a way that software

And we spent two years batting that topic around in 6renum, for site/enterprise networks (not targeting homenets).

IPv6 network renumbering on the wire = reasonably straight forward (Fred’s work is now 10 years old)
The complexity is all the places addresses are embedded in interesting ways, in your sites and sites you speak to.

Three RFCs emerged, see http://datatracker.ietf.org/wg/6renum/

Tim

---

From: Gert Doering <[email-masked]>
Date: Wed, 28 May 2014 11:52:04 +0200

Hi,

> What's your solution for them?

These requirements can be perfectly well met with "renumbering when they
change provider", except for 4. - if a bit of planning is involved, and
not trying to stick to last century's technology.

Like: use mDNS or AD-provided DNS to find your printer and file server
(so the actual address it has today does not really matter).  Think twice
whether you really want to run your web site locally, instead of hosting
it somewhere which has more bandwidth, proper 7x24 operations, etc.

And indeed it would be nice if firewall vendors would hear the message
that being able to specify rules referencing a DHCPv6-PD-acquired prefix
is a needed thing...

But of course, you can provide all technology there is, and someone will
still want NAT.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 May 2014 10:52:11 +0100

On 28 May 2014, at 06:08, Mikael Abrahamsson <[email-masked]> wrote:

> We should spend more time on getting renumbering working properly. Having all Enterprise get PI space will make the routing system melt down.

I think it was Brian who did some analysis a few years ago on just how many “large sites” are out there.  It’s not *that* scary a number.  Though nor is it small.  Obviously if you include homenets the meltdown is massive, but no one in the homenet wg is proposing PI for homenets.

Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 May 2014 08:11:41 -0400

On May 27, 2014, at 11:12 PM, Lorenzo Colitti <[email-masked]> wrote:
> You don't need ULA to solve this. homenet is solving this problem using source+destination routing. 

Er, homenet is (likely) using ULAs, just not as a way to finesse multi-homing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 May 2014 08:21:18 -0400

> to support SADR is harder than persuading them to allow multiple prefixes.

Do we have implementations we could in theory try to persuade them to run?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 May 2014 08:24:42 -0400

> We should spend more time on getting renumbering working properly. Having all Enterprise get PI space will make the routing system melt down.

This is what I was getting at, and you and Brian have both confirmed my original understanding.   Thanks.

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 May 2014 13:34:26 +0100

> Er, homenet is (likely) using ULAs, just not as a way to finesse multi-homing.

ULAs internally, plus SADR for externally provided prefixes when multihomed and multiaddressed. This has been demonstrated 3 or 4 IETFs ago in the siderooms/bits’n’bites sessions.  I think there’s an architecture doc around somewhere about it...

Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 May 2014 08:35:28 -0400

> Three RFCs emerged, see http://datatracker.ietf.org/wg/6renum/

There were, unfortunately, lots of interesting gaps... :)

---

From: Sander Steffann <[email-masked]>
Date: Wed, 28 May 2014 14:38:19 +0200

Hi Mikael,

> We should spend more time on getting renumbering working properly. Having all Enterprise get PI space will make the routing system melt down.

Either that, or coming up with a routing protocol that can handle the number of prefixes..

Cheers,
Sander

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 May 2014 13:40:24 +0100

> Either that, or coming up with a routing protocol that can handle the number of prefixes..

You may still need renumbering tools even without changing provider.

tim

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 28 May 2014 13:48:36 +0100

> Either that, or coming up with a routing protocol that can handle the number of prefixes..

it's not the routing protocol that matters but the FIB capacity on the
routers.  Churn and RIB size are not causing problems.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 May 2014 14:15:48 +0000

> From: v6ops [mailto:[email-masked]] On Behalf Of Tim Chown
> Sent: Wednesday, May 28, 2014 2:28 AM
> To: Brian E Carpenter
> Cc: Philip Homburg; v6ops WG
> Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks]
> 
> 
> Tests that Fernando and I reported at the last IEPG show around 50% of the Alexa top 1m sites which
> support IPv6 also drop frags.  Tests for other types of EH are far from encouraging too.

Then, how are we ever going to support tunnels over IPv6?

Thanks - Fred
[email-masked]

> >>>> or use NAT.  I'm not saying this in order to throw fuel on an existing fire, but simply because
> this is the reality fo
> >>>> r many organisations in the

---

From: Philip Homburg <[email-masked]>
Date: Wed, 28 May 2014 16:23:14 +0200

>Then, how are we ever going to support tunnels over IPv6?

Measurements using RIPE Atlas suggest that most filtering is done near the edges.
So if you want a tunnel, make sure that your site and the remote site don't do that
kind of filtering.

In addition, fragmentation involving DNS seems to work way better than sending
fragmented packets to the Alexa top 1m sites. So the kind of filtering you encounter
may also depend on where you look.

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 May 2014 15:36:47 +0100

Hi,

> may also depend on where you look.

Do you have a pointer to these results?

Thanks,
Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 May 2014 14:37:10 +0000

Hi Philip,

> From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Wednesday, May 28, 2014 7:23 AM
> To: v6ops WG

Interesting, but I'm not sure how that would play for "opportunistic"
tunnels where there may not be a way to manipulate the filters at the
remote site. 

> may also depend on where you look.

OK. But additionally in the tunnel case we need IPv6 fragmentation
to work across whatever opportunistic path the tunnel happens to
traverse.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Wed, 28 May 2014 17:16:31 +0200

In your letter dated Wed, 28 May 2014 15:36:47 +0100 you wrote:
>> Measurements using RIPE Atlas suggest that most filtering is done near =
>the edges.
>> So if you want a tunnel, make sure that your site and the remote site =
>don't do that
>> kind of filtering.
>>=20
>> In addition, fragmentation involving DNS seems to work way better than =
>sending
>> fragmented packets to the Alexa top 1m sites. So the kind of filtering =
>you encounter

I'm not aware of any measurements using RIPE Atlas that sent fragmented traffic to
the Alexa top 1m. In general, TCP does not generate that kind of traffic so it 
doesn't seem to be a real world scenario.

The people from NLnetlabs did use Atlas to look at fragmentation in the context 
of DNS. The main publication is 
https://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

Section 5.4 provides an analysis of where blocks happen.

Other measurements using ICMP get in the same ballpark as the DNS results.
https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters

It is possible to directly run PMTU experiments on Atlas, but as far as I know nobody 
reported on that.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 28 May 2014 08:32:36 -0700

On May 28, 2014, at 2:21 AM, Tore Anderson <[email-masked]> wrote:

> You don’t need an ASN to use PI space.

Except possibly in the APNIC region due to previously discussed very high fees,
I’m not sure why you think PI space is not practical for small organizations. I’ve
set up multi homed connections for a number of small businesses, including even
some one-man operations with gross revenues under US $250,000 annually.

>> failover or traffic shaping

Which makes an ASN and a PI prefix the easiest tactic possible.
(Even easier than NAT, really.)

> customer just gets a bunch of addresses he can use in perpetuity.

Exactly, but it does have the drawback of black holing traffic in certain
failure modes. If you really want to avoid an ASN (not sure why), it is
possible to do this using a private ASN that is stripped off by the
upstream provider(s), but using a real ASN is much simpler.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 May 2014 08:40:04 +1200

> Do we have implementations we could in theory try to persuade them to run?

I was referring to SADR in a site border router that leads to two
different ISPs. That, I understand, is readily available but requires
extra config and extra cycles.

SADR for a host to select the next hop indeed needs new stuff, afaik.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 May 2014 08:57:47 +1200

Tore,

On 28/05/2014 21:21, Tore Anderson wrote:
> prefix for them, 

The important words there are "a few". As long as the numbers are
reasonable, this scales. When the numbers cease to be reasonable,
it doesn't scale. The estimate I made some years ago, based on
a little research into statistics in a few countries, was that
there must be about 10 million small or medium enterprises in the
world. We don't know how to route 10M prefixes in BGP-4. So
somewhere between "PI for a few customers" and "PI for every
enterprise", we have to stop.

See the RRG archives.

    Brian

which costs next to nothing in the RIPE region at

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 28 May 2014 14:24:58 -0700 (PDT)

Hi Brian,

>________________________________
>Cc: Liubing (Leo) <[email-masked]>; v6ops WG <[email-masked]> 
>Sent: Wednesday, 28 May 2014 12:33 PM
>Subject: (re)numbering [ULA draft revision #2 Regarding isolated networks]
> 
>
>Hi Mark,
>

<snip>

>That's horrible.

Certainly was.

While obviously not correct behaviour, I think it shows that internal connectivity should be impervious to external connectivity changes and failures.

RFC1918s have provided that internal connectivity robustness to both home networks and enterprise networks. Of course the drawback is that in IPv4 it is binary - hosts either have RFC1918s or public addresses, so if you have RFC1918s you have to use NAT to access external destinations on the Internet.

Fortunately in IPv6 we can support both ULAs + Globals concurrently, having both independent internal connectivity as well as global connectivity, which is why I think there is a lot of value in a network (home net or enterprise) having ULA addressing for internal reachability, regardless of whether it is isolated or not from the Internet. ULAs reduce external dependencies, and I think doing that increases robustness (sure there is a cost, but everything is a trade-off).

The use case I like to imagine is a home user streaming a video from their NAS to their TV over their internal network. That should use ULAs so that a failure of their Internet connection/Global addressing has no impact on watching their movie. If the movie failed because the Internet connection/global addressing failed, that user will call the ISP's helpdesk. But why should it fail! The home users internal network is fine, it is only external connectivity that has failed. 

People might argue that enterprise networks are different and they are - they're simpler! Enterprise networks have technical staff on hand that can troubleshoot networks and resolve faults. If you can make IPv6 work seamlessly for home networks and their non-technical "operators", you've solved the harder problem. Since enterprise networks also value the same things home networks do - seamless operation, robustness against failure, stable internal connectivity, you've solved most of the enterprise network problems too.

> It doesn't conform to RFC 7084 either, which clearly

>states that "prefix(es) (and ULA prefix if configured...)" must

The precursor to 7084 (6204) was in development at the time, but it wouldn't have helped because they were ignoring our feedback. (Another CPE vendor was much better and almost too keen - they were sending me new software to test within 24 hours after reporting an IPv6 issue.)

Regards,
Mark.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 28 May 2014 23:52:38 +0200

* Owen DeLong

>> least, and advertise the prefix on their behalf (and in the cases 
>> where there's a second upstream, the second upstream does the 
>> same). Works perfectly well, and is much less complex than
>> anything solution involving ULA, NAT, multiple prefixes on the
>> hosts, or whatever. The customer just gets a bunch of addresses he
>> can use in perpetuity.
> 
> Exactly, but it does have the drawback of black holing traffic in 
> certain failure modes.

If the upstream starts blackholing in his core network somewhere and the
customer is singlehoming, he's toast no matter how he's connected to the
upstream. If he's multihoming, however, he can just physically pull the
plug or shut the interface and traffic converges on the remaining good
upstream, in pretty much in the same way it would if he used BGP.

Of course, if the problematic upstream provider doesn't withdraw the BGP
announcement when the customer shuts his interface then there's still
going to be a problem, but that's equally true both for connections with
or without BGP between the provider and the customer.

Blackholing of traffic during failure modes is something you can get
with any form of deployment. The way I see it, the use of BGP or non-use
of BGP doesn't really change the risks of this happening either for the
worse or the better. So I don't quite see why you call this a «drawback».

> If you really want to avoid an ASN (not sure why), it is possible to
> do this using a private ASN that is stripped off by the upstream
> provider(s), but using a real ASN is much simpler.

It's not I who want to avoid it, it's the end user. He doesn't
necessarily know how internet routing works, how to set up or operate
BGP, have equipment that can do so [without extra licences], and so
forth. Even if he does, he might not want the extra bother. So the point
isn't to avoid an ASN - if the customer is going to use BGP it's simpler
with an ASN than without - but to avoid requiring BGP.

Where the end user simply wants plain no bells-and-whistles internet
service, but require addresses that work with >1 upstream provider
simultaneously or which may be kept should he decide to switch providers
in the future, using a PI prefix that his upstream(s) originate into the
DFZ on his behalf is a really simple solution that actually works today
both for IPv6 *and* IPv4 (if you have them, that is). It's much less
complex than any solution I've seen that involves ULAs, NPT/NAT, BGP,
multi-prefixes, or anything else, which makes it my preferred way of
catering to the customers in question - for now.

Tore

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 May 2014 07:05:53 +0900

> We don't know how to route 10M prefixes in BGP-4.

i guess you have not seen large bgp-signaled vpns

the point is not whether we know how to.  the point is that we may
prefer not to.  but as in most frog boilings, this is not going to
drop on us like a brick next tuesday.

but this is a really smelly red herring.  you are talking about
replacing ula with real global addresses.  they should not be globally
announced anyway.

randy

---

From: Tore Anderson <[email-masked]>
Date: Thu, 29 May 2014 00:09:38 +0200

* Brian E Carpenter

> enterprise", we have to stop.

For sure, it is a very small minority of my customers who have this
requirement. The vast majority are perfectly happy to be assigned
prefixes out of my PA block. This goes for IPv4 too, BTW.

I seriously doubt that a significant fraction of those 10M enterprises
asking for a PI prefix (or multihoming at all) is a realistic scenario.
So I'm not too worried about IPv6 PI to be honest, we survived IPv4 PI
so far and I think we'll survive IPv6 PI also, even if adding a few
"new" PI holders who in IPv4 multihomed using PA assignments from their
upstreams + NAT44 + RFC1918. Especially if homenet comes up with an even
more attractive solution than PI for that specific use case soon.

Tore

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 May 2014 08:30:20 +1000

In message <[email-masked]>, Owen DeLong write
s:
> I'm not sure why you think PI space is not practical for small
> organizations. I've

Because it is actually more error prone than ULA when you are not
able to use the prefix for routing as there is no automatic built
in support.  Also running two GUA in parallel (PA + non-routeable
PI) will be harder to debug.  I realise that your PI is being routed.
You are the exception here.

This will actually encourage more NATPT or traditional NAT than ULA
will as the defaults are right for ULA + PA.

You are trading off P(collision) of epsilion when merging two ULA
domains with a continual debugging and configuration issues.  Every
time you add a router you need to remember to filter this prefix
to get ICMP unreachable returned.  If you have multiple sites then
you have lots of per site configuration.

With ULA I can see fd..... and identify that it is a ULA address
so I can easily see when a node is choosing the wrong address when
debugging.

Remember also homenet is doing SADR.  It so there will be even more
pressure to not announce yet another prefix as support for that
gets added to the very low end CPE devices.  If they can do it all
the more professional devices will need to support it so there will
be no escaping it.

If you get to the stage where you can get a PI routed, then sure use
that, but until you are at that stage non-routed PI is actually worse.

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 May 2014 09:11:54 +0900

>> We should spend more time on getting renumbering working
>> properly. Having all Enterprise get PI space will make the routing
>> system melt down.

red herring.  global prefixes designed to be used in place of ula should
not be in the global routing table

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 May 2014 15:33:51 +1200

> not be in the global routing table

Indeed they shouldn't, but since everybody should be filtering ULAs
(and most people will do so), ULAs won't propagate but routeable GUAs
might.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 May 2014 12:44:01 +0900

> (and most people will do so), ULAs won't propagate but routeable GUAs

explain why the two probability distributions will differ

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 May 2014 16:00:31 +1200

> explain why the two probability distributions will differ

Because I have considerable confidence that the majority of transit
operators will know they need to filter fc00::/7, but the same cannot
be said of arbitrary /48s from RIR space.

    Brian

---

From: Matthew Petach <[email-masked]>
Date: Thu, 29 May 2014 04:18:06 -0700

On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith <[email-masked]>
wrote:
[...]

> RFC1918s have provided that internal connectivity robustness to both home
> networks and enterprise networks. Of course the drawback is that in IPv4 it
> is binary - hosts either have RFC1918s or public addresses, so if you have
> RFC1918s you have to use NAT to access external destinations on the
> Internet.
>

Wow...that's news to me.

For a decade now, I've been using
RFC1918 addresses+global addresses
in IPv4 on my home network; each
host has an address from each subnet,
and uses the 1918 addresses to reach
internal-only devices (printers, terminal
servers, etc.) which only have RFC1918
addresses, and use the globally routed
IPs for reaching non-local destinations.

I'm not sure I'd agree with your characterization
that IPv4 is different from IPv6 in that regards;
there's nothing in the IPv4 world that prevents
hosts from having multiple addresses, and
making use of them.

It's definitely a plus to have internal connectivity
stay working regardless of external connectivity,
I completely agree with you on that.

Matt

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 May 2014 21:24:17 +0900

> be said of arbitrary /48s from RIR space.

i know.  that's why we see no leaks of rfc1918 and ULA today.  oh ...
oops!

the real measurement i would take is to test the hypothesis that utterly
unrealistic fantasies about operations are highest in v6 religious wgs.

randy

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 May 2014 14:26:38 +0200

hi,

> all Enterprise get PI space will make the routing system melt down.

I think this one boils down to "what is 'an Enterprise'" and, subsequently,
"how many of those are there".

One side of the discussion seems to include barbershops etc. ("SME") in
this group - and there are way too many of them, but renumbering those
networks is usually trivial ("what is my printer's IP address?" is nicely
answered by mDNS, so no need to hard-code IPv6 addresses anywhere where
you'd have to renumber them alter on... etc.).

The truly big ones are not candidates for renumbering, but we're talking
about significantly smaller numbers here :-)  (and, interestingly enough,
many of them don't *want* Internet in the first place, they want an internal
network, a proxy server, and that one can easily renumber if needed...)

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 May 2014 14:42:27 +0200

Hi,

> to support SADR is harder than persuading them to allow multiple prefixes.

It needs to be pointed out again and again that the problem space

  "network without IT administrator/IT department"

and

  "network with IT department"

is sufficiently different that SADR is a tremendously great solution for 
one of them, and a completely no-go for the other.  Which one is which,
and why, is left as a trivial excercise for the reader :-)

Gert Doering
        -- NetMaster

---

From: David Farmer <[email-masked]>
Date: Thu, 29 May 2014 08:46:29 -0500

> be said of arbitrary /48s from RIR space.

Here is some data supporting the idea that GUA used as ULA can and will 
be leaked, leaked a lot in some cases.

See slide 20 of the following presentation;
https://www.nanog.org/meetings/abstract?id=2289

And this is discussed in more detail in section 5.2 of the full research 
paper at;
http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

Yes, I'm sure ULA is leaked too.  However, it's a much safer assumption 
and operationally much easier to filter external ULA sourced traffic. 
Even if I'm exchanging ULA traffic with other parties, it would seem 
likely for me to know the ULA prefixes that matter to me.

Where as, if someone uses GUA as if it were ULA and it's leaked, it's 
extremely unlikely that I would know to filter it.  The only way I can 
even think of is for the other entity to publish ROAs sourced to AS0. 
However, I suspect the security guys would object to that, as I'm now 
leaking that traffic from that prefix might be interesting.  One of 
those dammed if you do, dammed if you don't kind of situations.

Those of you suggesting no one should use ULA and should get GUA and use 
it as if it's ULA need to write up some recommendations for how to do it 
safely.  It seems many people are following your recommendations but 
doing it badly.

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 29 May 2014 11:00:37 -0400

> i know.  that's why we see no leaks of rfc1918 and ULA today.  oh ...

Leaks are there, however they are identifiable without knowing much about why someone is using them.  So even if
someone leaks it, others can filter.

Victor K

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 May 2014 01:32:11 +1000

In message <CAEmG1=rz=[email-masked]>
> I completely agree with you on that.

It may work with some machine some of the time.  It is not guarenteed
to work with all machines all of the time.  I've definitely used
machines which didn't support multiple IPv4 addresses on the same
interface.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 29 May 2014 14:49:50 -0700 (PDT)

----- Original Message -----
> From: Randy Bush <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Cc: v6ops WG <[email-masked]>
> Sent: Thursday, 29 May 2014 10:24 PM

It certainly would be better if it didn't happen, but what significant harm does it cause if it does? When did the Internet stop because RFC1918s were in the DFZ?

Even if one AS accepts them, why are that AS's peers also accepting them? Isn't that either a statement of how undisciplined a significant number of operators are being at ingress prefix filtering, or conversely, a statement that the problem of private address space leaking into the DFZ isn't as significant as you're saying it is, and operators aren't spending time on policing it because they've got more significant problems to worry about?

The origin AS and the AS path it took is available, so it should be easy to chase down the perpetrator and those who are aiding and abetting.

> unrealistic fantasies about operations are highest in v6 religious wgs.

If you're worried about these sorts of things, wouldn't it be better to chasing people doing far worse damage to the DFZ, like those not aggregating PI when they should be? Going by the latest reports, there's up to 220K route table slots to be saved.

---

From: George Michaelson <[email-masked]>
Date: Fri, 30 May 2014 09:15:45 +1000

How long ago Mark. How old, What OS.

If this is a UNISYS mainframe which used , to separate the elements of the
dotted-quad for instance (yes, that really happened) we'd be entitled to
say "so what"

if this is a Vista or newer OS, we need to know.

On Fri, May 30, 2014 at 1:32 AM, Mark Andrews <[email-masked]> wrote:

>
> In message <CAEmG1=rz=
> [email-masked]>
> , Matthew Petach writes:
> >

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 May 2014 10:45:41 +1000

In message <CAKr6gn1DTUnt=9UbQjmCSsk9ZHUpVJtwQM2u7xp0-J=[email-masked]>
> How long ago Mark. How old, What OS.

A Brother HL-4040CN printer only supports a single IPv4 address and
it has IPv6 support.  To be fair only supports configuring a single
static IPv6 address but will autoconf multiple ones.  It currently
3 IPv6 addresses (PI + ULA + LL).

This is the difference between what is required by a host/node for
IPv4 and IPv6.  Support for multiple prefixes is required for IPv6.
It isn't required for IPv4.

> --047d7b15abb1c861ed04fa921bb7
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">How long ago Mark. How old, What OS.<div><br></div><div>If=
>  this is a UNISYS mainframe which used , to separate the elements of the do=
> tted-quad for instance (yes, that really happened) we&#39;d be entitled to =
> say &quot;so what&quot;</div>
> <div><br></div><div>if this is a Vista or newer OS, we need to know.</div><=
> /div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, =
> May 30, 2014 at 1:32 AM, Mark Andrews <span dir=3D"ltr">&lt;<a href=3D"mail=
> to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"><br>
> In message &lt;CAEmG1=3Drz=3D<a href=3D"mailto:o3adK5a7M5DOFGVa1GnjKxj3bNRq=
> [email-masked]">o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mai=
> l.gmail.com</a>&gt;<br>
> <div><div class=3D"h5">, Matthew Petach writes:<br>
> &gt;<br>
> &gt; On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith &lt;<a href=3D"mailto:=
> [email-masked]">[email-masked]</a>&gt;<br>
> &gt; wrote:<br>
> &gt; [...]<br>
> &gt;<br>
> &gt; &gt; RFC1918s have provided that internal connectivity robustness to b=
> oth home<br>
> &gt; &gt; networks and enterprise networks. Of course the drawback is that =
> in IPv4 it<br>
> &gt; &gt; is binary - hosts either have RFC1918s or public addresses, so if=
>  you have<br>
> &gt; &gt; RFC1918s you have to use NAT to access external destinations on t=
> he<br>
> &gt; &gt; Internet.<br>
> &gt;<br>
> &gt; Wow...that&#39;s news to me.<br>
> &gt;<br>
> &gt; For a decade now, I&#39;ve been using<br>
> &gt; RFC1918 addresses+global addresses<br>
> &gt; in IPv4 on my home network; each<br>
> &gt; host has an address from each subnet,<br>
> &gt; and uses the 1918 addresses to reach<br>
> &gt; internal-only devices (printers, terminal<br>
> &gt; servers, etc.) which only have RFC1918<br>
> &gt; addresses, and use the globally routed<br>
> &gt; IPs for reaching non-local destinations.<br>
> &gt;<br>
> &gt; I&#39;m not sure I&#39;d agree with your characterization<br>
> &gt; that IPv4 is different from IPv6 in that regards;<br>
> &gt; there&#39;s nothing in the IPv4 world that prevents<br>
> &gt; hosts from having multiple addresses, and<br>
> &gt; making use of them.<br>
> &gt;<br>
> &gt; It&#39;s definitely a plus to have internal connectivity<br>
> &gt; stay working regardless of external connectivity,<br>
> &gt; I completely agree with you on that.<br>
> &gt;<br>
> &gt; Matt<br>
> <br>
> </div></div>It may work with some machine some of the time. =C2=A0It is not=
>  guarenteed<br>
> to work with all machines all of the time. =C2=A0I&#39;ve definitely used<b=
> r>
> machines which didn&#39;t support multiple IPv4 addresses on the same<br>
> interface.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> <br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE=
> RNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
> _______________________________________________<br>
> v6ops mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">h=
> ttps://www.ietf.org/mailman/listinfo/v6ops</a><br>
> </div></div></blockquote></div><br></div>
> 
> --047d7b15abb1c861ed04fa921bb7--

---

From: Owen DeLong <[email-masked]>
Date: Thu, 29 May 2014 18:01:56 -0700

> extra config and extra cycles.

Most administrators in the enterprise world refer to this as “policy based routing” as
that’s what many of the vendors call it, too.

It almost always comes with the additional baggage of dropping you out of fast-path
hardware forwarding onto control-plane based forwarding.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 29 May 2014 18:41:42 -0700

> upstream, in pretty much in the same way it would if he used BGP.

If I’m advertising to the upstreams via BGP, then when I drop the routes to
them, they stop advertising them to the world and thus there’s no black hole.

OTOH, when you’re advertising my routes on a static basis without peering with
me, then if I drop my connection to you, your routers don’t know/don’t care and
still keep advertising my routes.

> or without BGP between the provider and the customer.

Sure, but it’s much more common in the scenario you described than in the
scenario where the customer is sending you BGP announcements and you don’t
know about the customer’s prefix other than when you hear it from the customer
via BGP.

> worse or the better. So I don’t quite see why you call this a «drawback».

Then you are living in an imaginary world where magic happens without a routing
protocol to prevent continued advertisement of a prefix that no longer has a
feasible successor. In the real world, this usually doesn’t happen without a routing
protocol.

> with an ASN than without - but to avoid requiring BGP.

Since I can run sufficient BGP for an end site on a Raspberry PI with a
second ethernet, using free software, I have trouble buying that argument.

As to the “how to configure” problem, that’s 2 hours (max) of some consultants
time (any smart ISP offers this as a professional services value add) and
can be pretty much fire and forget for the scenario in question.

> catering to the customers in question - for now.

It’s really not less complex than BGP where the customer advertises his
prefix and receives default. Nor does it require particularly expensive
hardware. Admittedly, the R-PI is probably a little too low-brow for
most situations, but a Juniper SRX-100, <$200 Mikrotik, or a variety of
other solutions can be made to work for ≤$600 total hardware and software.
Most of them can even take a full IPv6 table, while you get into real money
if you want a full IPv4 table.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 29 May 2014 18:45:01 -0700

> You are the exception here.

Who says we didn’t use the prefix for routing. All of the situations
I was describing are doing BGP with their upstreams and advertising the
prefixes in question.

> will as the defaults are right for ULA + PA.

They’re even more right for PI+Routing.

> you have lots of per site configuration.

Only if you’re not using the prefix for routing.

> so I can easily see when a node is choosing the wrong address when

Sure.

> the more professional devices will need to support it so there will

We’re not talking about home net here, though I’d never implement what
home net is currently considering in my home.

> that, but until you are at that stage non-routed PI is actually worse.

My point is that the point where that stage occurs is MUCH MUCH lower than
many people appear to think it is.

It can be done on very cheap hardware with free software very effectively for
very little cost.

Owen

---

From: Matthew Petach <[email-masked]>
Date: Fri, 30 May 2014 03:19:48 -0700

> 3 IPv6 addresses (PI + ULA + LL).

Hm.  OK.  In my setup, only the hosts
need to support multiple addresses;
the peripheral devices are only on
the internal network, so there's
never been a need for them to
support multiple addresses.

Thanks for pointing that out.

Matt

> > > > > RFC1918s have provided that internal connectivity robustness to
> both
> > > home
> > > > > is binary - hosts either have RFC1918s or public addresses, so if
> you
> > > have
> > [email-masked]
> ">o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mai=
> > l.gmail.com</a>&gt;<br>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 30 May 2014 19:30:57 +0900

> host has an address from each subnet,

How do you configure the hosts? Manually?

Manual configuration would be a non-starter in many situations.

---

From: t.petch <[email-masked]>
Date: Fri, 30 May 2014 13:57:51 +0100

----- Original Message -----
From: "Tore Anderson" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "V6 Ops List" <[email-masked]>
Sent: Wednesday, May 28, 2014 11:09 PM

Tore

The damage done by PI in IPv4 was understood before the RIRs  started
handing out addresses in large numbers, so while PI exists, it has
always been hard to get.

The fear with IPv6 is that just because one constraint on PI has been
removed, those handing out addresses will not realise that there is
another show-stopping constraint in the number of entries a FIB can cope
with, 1M being the best estimate (as before, on the RRG list) with the
foreseeable improvements to current technology.

And I think that every SME who has lost business with the unreliability
of their ISP will want multi-homing and will think that with IPv6 and PI
the constraints have gone, and the number of such SMEs can only approach
10M over time.

So, Brian is spot on, and just as the IETF did little about IPv4
addresses running out until the event loomed large, so I expect history
to repeat itself with the growth of PI in IPv6.

Tom Petch

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 30 May 2014 14:45:52 +0100

> foreseeable improvements to current technology.

several varieties of current generation hardware can handle 1m ipv6 fib.
We're at 17k ipv6 prefixes now, and the growth rate has been linear since
2011.  There is a fear about ipv6 fib size, not fully matched by evidence.

Nick

---

From: Ca By <[email-masked]>
Date: Fri, 30 May 2014 06:53:41 -0700

> 2011.  There is a fear about ipv6 fib size, not fully matched by evidence.

Not my *new* gear. And not while running a full ipv4 table too.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 30 May 2014 15:09:31 +0100

> Not my *new* gear. And not while running a full ipv4 table too.

tom specifically mentioned "1M being the best estimate ... with the
foreseeable improvements to current technology" but we already have this on
e.g. asr9000 typhoon cards.  Whether your particular boxes handle a 1m v6
fib is a different issue; the point is that the technology already exists
and given the small DFZ and (currently) linear growth rate, there is no
short / medium term fear here, and arguably no long term cause of concern
either.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 30 May 2014 15:13:29 +0100

On 30/05/2014 15:09, Nick Hilliard wrote:
> e.g. asr9000 typhoon cards. 

correction: typhoon cards have 4M FIB "credits".  ipv4 entries take one
credit; ipv6 take two.  So assuming no ipv4, a typhoon card will handle 2m
ipv6 FIB entries.

Nick

---

From: John Curran <[email-masked]>
Date: Fri, 30 May 2014 10:21:36 -0400

> credit; ipv6 take two.  So assuming no ipv4, a typhoon card will handle 2m

Acceptable end state does not imply viable intermediate states.

/John

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 30 May 2014 15:37:21 +0100

> Acceptable end state does not imply viable intermediate states.

itym, "acceptable intermediate states do not imply viable end state".

We can all agree to that, but we have 60x overhead on current generation
technology and linear growth.  There are more pressing problems than this.
 Let's deal with them instead.

Nick

---

From: Owen DeLong <[email-masked]>
Date: Fri, 30 May 2014 07:44:06 -0700

> foreseeable improvements to current technology.

Yes, we need to change the fundamental way we deal with routing and come up
with a more scalable solution than the current everyone knows every prefix
model.

However, at any likely growth rate, if we actually start working on the problem
instead of simply inflicting limitations and calling it handled, then we have
time to address the issue in IPv6. Hopefully the RRG will wake up and start
addressing this issue. For now, it is out of scope for v6ops as I understand
the WG charter.

> the constraints have gone, and the number of such SMEs can only approach

All the more reason this issue needs to get addressed instead of ignored.

> to repeat itself with the growth of PI in IPv6.

He’s somewhat right about the problem. He’s absolutely wrong in believing that
the current limitations are a solution.

Owen

---

From: John Curran <[email-masked]>
Date: Fri, 30 May 2014 10:48:57 -0400

> itym, "acceptable intermediate states do not imply viable end state".

No, I mean that the fib capacity _assuming no IPv4_ (end state) is not 
particularly relevant, since most folks have to deal with IPv4 and IPv6 
at the same time.  While Geoff Huston's graphs show fairly predicable
historic IPv4 routing growth, we also have not experienced (yet) the 
significant pressure to route smaller and smaller IPv4 remnants that 
is likely to occur as both regional and service provider free pools
begin to run out...

> Let's deal with them instead.

I'm not suggesting that there is a imminent crisis (or that any particular
work should be done/not be done with respect to ULA's), but was simply noting
that folks should not presume our current trajectory to be safe and assured, 
particularly based on the ability of the latest hardware to cope with an
IPv6-only world.

FYI,
/John

---

From: t.petch <[email-masked]>
Date: Fri, 30 May 2014 18:01:10 +0100

----- Original Message -----
From: "Owen DeLong" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Tore Anderson" <[email-masked]>; "Brian E Carpenter"
<[email-masked]>; "V6 Ops List" <[email-masked]>
Sent: Friday, May 30, 2014 3:44 PM
> foreseeable improvements to current technology.

Yes, we need to change the fundamental way we deal with routing and come
up
with a more scalable solution than the current everyone knows every
prefix
model.

<tp>
Owen,

yes, and that is what the RRG did.  It came up with two solutions and,
being an IRTF and not an IETF WG, one solution was declared appropriate
while the other (LISP) is being developed by the IETF:-)

The key to both is that while the number of prefixes is likely to grow
beyond the capacity of routers, the number of locations involved is
likely to remain much smaller so that routing will be based on
locations, with a mapping from prefix to location prior to routing.

All in the RRG archives.

Tom Petch

However, at any likely growth rate, if we actually start working on the
problem
instead of simply inflicting limitations and calling it handled, then we
have
time to address the issue in IPv6. Hopefully the RRG will wake up and
start
addressing this issue. For now, it is out of scope for v6ops as I
understand
the WG charter.

> the constraints have gone, and the number of such SMEs can only
approach

All the more reason this issue needs to get addressed instead of
ignored.

> to repeat itself with the growth of PI in IPv6.

He’s somewhat right about the problem. He’s absolutely wrong in
believing that
the current limitations are a solution.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 30 May 2014 10:18:46 -0700

> while the other (LISP) is being developed by the IETF:-)

Not sure why your mailer can’t do quoting correctly, but I’ve fixed it here
for you.

> locations, with a mapping from prefix to location prior to routing.

LISP is way over-complicated for the problem space in question, though it’s
probably the right general idea.

In reality, what is needed is a simpler solution probably related to doing
the IDR portion of routing on destination ASN. Unfortunately, we don’t have
a good way in the current protocol to encode the destination ASN onto the
packet. My thinking is that a revised 44 octet header would do the trick and
that during the transition process, having routers that border between
44-octet header capable zones and non-44-octet header capable zones would
perform the header replacement. Unfortunately, this has PMTU-D issues which
I haven’t figured out how to address yet.

Owen

---

From: Tore Anderson <[email-masked]>
Date: Fri, 30 May 2014 19:22:36 +0200

* t.petch

> The damage done by PI in IPv4 was understood before the RIRs
> started handing out addresses in large numbers, so while PI exists,
> it has always been hard to get.
> 
> The fear with IPv6 is that just because one constraint on PI has
> been removed, those handing out addresses will not realise that there
> is another show-stopping constraint in the number of entries a FIB
> can cope with, 1M being the best estimate (as before, on the RRG
> list) with the foreseeable improvements to current technology.
> 
> And I think that every SME who has lost business with the
> unreliability of their ISP will want multi-homing and will think that
> with IPv6 and PI the constraints have gone, and the number of such
> SMEs can only approach 10M over time.

I'm only familiar with the RIPE region's policies, but PI certainly
wasn't «hard to get» for an SME here that wanted to multi-home (until
the point where we stopped completely issuing new blocks of it, that
is). It only had to do the following:

1) Pick a sponsoring LIR out of the ~10k available to choose from, and
2) Fill out the appropriate request form, and
3) Be prepared to pay a yearly fee of €50 (+ the LIRs profit margin).

The procedure was the same for IPv4 PI as it still is for IPv6 PI.

(The only real difference between IPv4 and IPv6 PI was the difficulty in
getting a large IPv4 assignment. While in IPv6 you get an enormous /48
with no questions asked, in IPv4 you only get a measly /24 and would
have to provide additional documentation if you wanted more. However
this difference is moot in a discussion of FIB sizes, as the scarce
resource is the routing table entries themselves, and the prefix length
of each individual entry is AFAIK irrelevant.)

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 May 2014 08:26:11 +1200

On 31/05/2014 02:44, Owen DeLong wrote:
...
> All the more reason this issue needs to get addressed instead of ignored.

We agree on that.

> the current limitations are a solution.

As far as I can parse that last sentence, I'm not sure I said that.

It isn't beyond the bounds of physics to believe that a 10 million
entry 128-bit wide FIB would be possible. (After all, we believe that
fully portable 10-digit phone numbers are possible.) But I'd rather
see a more elegant solution. Whether the RRG has found it yet is
another discussion.

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Fri, 30 May 2014 14:45:20 -0700

> see a more elegant solution. Whether the RRG has found it yet is

Agreed.

My point is that continuing to reject the idea of quasi-universal PI utilization and accepting that as a given limitation of the internet as a whole is an obsolete idea and continuing to treat it as axiomatic only delays the possibility of a genuine solution.

I think we could, actually, learn a little from the phone system here. They provide number portability by using two separate (but similar looking) address spaces operated in a process not significantly dissimilar from DNS. The dialed number is looked up in a map which provides a connecting address which is topologically based. LISP sort of looks like this, except that it is much more complicated in its implementation than I believe is warranted for the actual problem space.

It's really too bad we didn't tackle this problem when designing the IPv4 header. An additional 32 bit wide field for Destination ASN may have been all we needed.

Owen

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 30 May 2014 23:44:04 +0000

> to repeat itself with the growth of PI in IPv6.

Which is something we have pointed out for quite some time, and tried to advocate the use of PA prefixes for, but had issues with people saying “why, when PI space is $50/prefix?”

Now, there are multiple problems with PA prefixes, not the least of which is that 8+8/ILNP/whatever has not been adopted, so PA basically moves complexity to the edge network without giving it a way to deal with it.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 30 May 2014 17:15:14 -0700

> Which is something we have pointed out for quite some time, and tried to advocate the use of PA prefixes for, but had issues with people saying “why, when PI space is $50/prefix?”

Advocating PA is not solving the problem, it's building in limitations on the end-user instead of solving the problem.

> Now, there are multiple problems with PA prefixes, not the least of which is that 8+8/ILNP/whatever has not been adopted, so PA basically moves complexity to the edge network without giving it a wa…

It's more than that. It also creates an unpleasant kind of fate sharing between end-site and ISP as well as some vendor-lockin problems. Bottom line, for many end-sites, PA is an acceptable tradeoff, but it is desirable to none. PI is universally better for the end-site, but requires an as yet unspecified solution to the scalability of the routing table.

People aren't just adopting PI because it's cheap. They're adopting PI because it is better suited to their needs than PA.

While PA is not nearly as damaging as NAT, it's just as anachronistic at this point and we really should be trying to find a solution that allows us to move on.

Owen

---

From: Randy Bush <[email-masked]>
Date: Sat, 31 May 2014 12:11:13 +0900

> 2011.  There is a fear about ipv6 fib size, not fully matched by evidence.

and, to repeat, in this discussion, global fib/rib size is a complete
red herring.  what is being discussed is globals for INTRANET, a
discussion i remember from the early '80s and probably that was a redux.

randy

---

From: Gert Doering <[email-masked]>
Date: Sat, 31 May 2014 12:36:30 +0200

Hi,

On Fri, May 30, 2014 at 02:45:20PM -0700, Owen DeLong wrote:
> I think we could, actually, learn a little from the phone system here. 

Yep.  I really like the flexibility of the number porting system in the
telephone world.  Like, you only have to tell them a few weeks in advance,
you can't have multihoming of the same phone number to different carriers
(unless you are a carrier yourself and get to sign the *large* stack of
paper first), and foremost, for international calls everything usually 
still goes through the Incumbent.

Indeed, there is lots to learn there why not to go there.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Sat, 31 May 2014 12:41:45 +0200

Hi,

On Fri, May 30, 2014 at 05:15:14PM -0700, Owen DeLong wrote:
> It's more than that. It also creates an unpleasant kind of fate
> sharing between end-site and ISP as well as some vendor-lockin
> problems. Bottom line, for many end-sites, PA is an acceptable
> tradeoff, but it is desirable to none. PI is universally better for
> the end-site

I challenge that.  For a end site with no technical understanding (like,
*most* of them), PI is not useful.  Not at all.

PA with automatic network (re-)numbering and multihoming with multiple
PA networks already works today, and will really work much more pleasantly
than PI *for those networks* as soon as we've sorted out some of the 
remaining kinks (like source-address selection with SA failover).

Maybe you should step down from your "I have PI, I like it, everybody must
have PI" soapbox and actually look at what, for example, homenet has 
achieved in the last years.  This stuff looks complicated (and under the
hood, it is), but the end user experience "take this box, plug in a number
of ISPs, things work, no further configuration is needed(*)" is nothing you
can match with a PI network.

(*) for the case "there's a cable hanging from the wall with DHCPv6-PD 
and RA in it".  For cases where you need to configure access credentials,
homenet cannot automate this, of course.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Sat, 31 May 2014 23:11:42 +0200

>can match with a PI network.

I can see how you can do do multiple PA prefixes client side. Done that
for years now. Even with different routers providing the upstreams. No problem
there.

But I have nothing to update my DNS zones. How do I reflect which links 
are up or down? Is there even a draft for that? What's the BCP for TTL
values, DNSSEC, etc?

---

From: Gert Doering <[email-masked]>
Date: Sat, 31 May 2014 23:31:33 +0200

Hi,

> are up or down? Is there even a draft for that? What's the BCP for TTL

This is where things get interesting.  You, Owen, I are not "the 99% home
users out there" - home users don't do DNS zones, because they do not 
control a DNS server...  (they do mDNS because it's automatic and works
fine for in-house purposes).   Where this falls apart, of course, is when
you need to setup some sort of "call me" service, like remote help, 
access your home disks from abroad, etc.

Some router vendors (AVM) have started to offer dyn-dns services that
attach the current (dynamic) prefix to a statically known host-id and
thus provide DNS to reach "home devices".  I'm not aware of specific 
drafts that govern how IETF thinks this *should* be done, though.

Gert Doering
        -- NetMaster

---

From: Mark Andrews <[email-masked]>
Date: Sun, 01 Jun 2014 07:49:08 +1000

> are up or down? Is there even a draft for that? What's the BCP for TTL

You have UPDATE + TSIG or SIG(0).  This is basically what Microsoft
do with Active Directory except they use GSS-TSIG for about 15 years
now.  UPDATE and DNSSEC just work and have for over a decade now.
Happy Eyeballs has proved that you don't need change the DNS for
link state changes.  IPv4 vs IPv6 is no different to PA1 vs PA2.
HE is all about the client working around a dead link.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 31 May 2014 23:55:22 +0200

>HE is all about the client working around a dead link.

My router is going to update DNS using UPDATE + TSIG? How does my router know
then names of my servers (or the actual addresses)?

Are servers going update themselves?

Is any of that spelled out?

I have no idea what software you are using, but only a tiny fraction of
the software I'm using actually uses happy eyeballs. 

You suggest that every possible piece of software should implement HE?

---

From: Mark Andrews <[email-masked]>
Date: Sun, 01 Jun 2014 08:23:21 +1000

> drafts that govern how IETF thinks this *should* be done, though.

The IETF has published exactly one method for updating the DNS (RFC 2136).
It has standardized several methods for securing that update.

RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE)
RFC 2845: Secret Key Transaction Authentication for DNS (TSIG)
RFC 2931: DNS Request and Transaction Signatures ( SIG(0)s )
RFC 3645: Generic Security Service Algorithm for
         Secret Key Transaction Authentication for DNS (GSS-TSIG)

Now there are some other adhoc methods by various dynamic DNS
providers but UPDATE + TSIG and UPDATE + GSS-TSIG have been using
by enterprises for over a decade now depending upon whether you are
a Microsoft AD Enterprise (UPDATE + GSS-TSIG) or not (UPDATE + TSIG)
from the DHCP server.

UPDATE + TSIG work fine from a CPE device.
UPDATE + TSIG work fine from a node one you have configured shared TSIG
	keys.

TSIG is just username + password and when you present it as username
+ password it is understood by the average punter.

UPDATE + SIG(0) works fine from a node one the administrator has added
	the KEY record for the node to the zone usually using UPDATE + TSIG.
UPDATE + GSS-TSIG work fine for Microsoft AD sites where each node is
	add to the AD DOMAIN and gets a Kerberos key which it uses with
	UPDATE to update its own information.

All of these method work.  All of them can be in ACLs to restrict the updates
down to the RRset level.  Now if someone wants to write a BCP saying that
nodes should support UPDATE.  That nodes should add their addresses to the
DNS when they change I would be all for it.

Apple already do UPDATE + TSIG.
Microsoft already do UPDATE + GSS-TSIG.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Sun, 01 Jun 2014 08:58:03 +1000

> Are servers going update themselves?

Why not?  They know their own addresses.  They know their name.  If
you have a UNIX/Linux based box that shipped in the last 15 years
you have the tools to do this.  Having this done when the addresses
change is a matter of writing a small daemon or integrating it into
the DHCP client.

% nsupdate -k keyfile
update delete <servername> AAAA
update add <servername> 3600 AAAA <address1>
update add <servername> 3600 AAAA <address2>
update add <servername> 3600 AAAA <address3>
send
%

This deletes all the AAAA records and then adds in all the current
addresses.  This is a atomic transaction.  The nameserver adds
DNSSEC signatures if they are appropriate for the zone.

Similar for A records.

keyfile could contain a TSIG key or a KEY for SIG(0)

You can also do split horizon updates if you want to using multiple
TSIG keys to select the zone instance to be updated.

> You suggest that every possible piece of software should implement HE?

Yes.  RFC 1123 told every developer for the last 2 decades to support
multi-homed servers.

http://users.isc.org/~marka/ has simple example code for how to do
this for TCP clients.  UDP clients are slightly more complicated
as you have to it higher up the stack.  The client side of DNS
servers has been doing this sort of stuff for multiple decades now
but instead of trying to do a single connection they are dealing
with thousands of connections.

The code is slightly more complicated than that published in the
getaddrinfo man page but not much more.