Subject: RFC 3484 Section 6 Rule 9

From: Mark Andrews <[email-masked]>
Date: Mon, 02 Jun 2008 14:56:40 +1000

This rule should not exist for IPv4 or IPv6.  Longest match
	does not make a good sorting critera for destination address
	selection.  In fact it has the opposite effect by concentrating
	traffic on particular address rather than spreading load.

	I received a request today asking us to break up DNS RRsets
	as a workaround to the rule.    Can we please get a errata
	entry for RFC 3484 stating that this rule needs to be ignored.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Jun 2008 09:59:15 +0300 (EEST)

> 	entry for RFC 3484 stating that this rule needs to be ignored.

I doubt that. Errata seems like a wrong place to revisit WG decisions.

(I take no stance on the issue itself.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Mon, 02 Jun 2008 17:16:27 +1000

> (I take no stance on the issue itself.)

	Errata is a lot faster that getting out a new RFC and will provide
	a place that can be referred to in the meantime. 

	This rule is clearly wrong.

	If I have a 192/24 address what make another 192/8 address
	better than say 130.155/16 address?  Absolutely nothing.
	Rule 9 says that all 192/24 address are better than anything
	else if you have a 192/24 address.

	I don't think there is any real dispute that the rule is bogus.
	There is clear evidence that it does actual harm.

	Mark

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 02 Jun 2008 08:45:59 +0200

Well, longest prefix match is kind of useful in some scenarios i think.

Imagine a site that is multihomed to two ISPs and has two PA address blocks.

Now, longest prefix match ensures that when a node of the multihomed 
site wants to contact any other customer of its own isps, it does 
perform the correct source address selection and that is likely to be 
critical for the communication to work, especially if the isps are doing 
ingress filtering (i am assuming that the intra site routing of the 
multihomed site will preffer the route through the ISP that owns the 
prefix contained in the destiantion address)

Even though this is one case and the problem is more general, i tend to 
think that this is an importnat case and things would break more if this 
rule didn't exist

Regards, marcelo

---

From: SM <[email-masked]>
Date: Mon, 02 Jun 2008 02:13:07 -0700

Hi Mark,
>         a place that can be referred to in the meantime.

There is a Proposed IESG Statement Regarding RFC Errata for IETF 
Sream RFCs (see 
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04742.html 
).  There is also a RFC Editor Proposal for Handling RFC Errata (see
draft-rfc-editor-errata-process-02 ).

>         This rule is clearly wrong.

Quoting Section 1.1 of the above-mentioned draft:

   "Furthermore, posting technical errata for Standards Track documents should
    always involve the IESG, as a matter of correct process.  Technical errata
    may require much review and discussion among the author(s), Area Directors,
    and other interested parties."

   "We note that allowing technical errata is a slippery slope: there may
    be a temptation to use errata to "fix" protocol design errors, rather
    than publishing new RFCs that update the erroneous documents.  In
    general, an erratum is intended to report an error in a document,
    rather than an error in the design of the protocol or other entity
    defined in the document, but this distinction may be too imprecise to
    avoid hard choices."

>         There is clear evidence that it does actual harm.

Although an Errata is the path of least resistance, it may not be 
appropriate as this is a technical errata and RFC 3484 is on the 
Standards Track.  If there isn't any real dispute about the rule 
being bogus, it may be possible to publish an I-D and have it on a fast track.

Regards,
-sm

---

From: Mark Andrews <[email-masked]>
Date: Mon, 02 Jun 2008 23:50:07 +1000

> think that this is an importnat case and things would break more if this 

	Section 6 Rule 9 is DESTINATION address selection.  It
	provides absolutely no help when attempting to distingish
	a multi-homed destination that is not with your current
	ISP.  It also won't help once your current ISP has more
	than one prefix.  It doesn't help with PI clients connected
	to your current ISP.

	It biases what should be a random selection.

	There is no science that says a /30 match is better than a
	/28 or a /8 match.

	If one really wants to have directly connected clients of
	your ISP match then get a appropriate feed of prefixes and
	use it to build appropriate tables.  We have the technology
	to distribute sets of prefixes.

	Just don't attempt to have longest match do the just because
	it can't do it except for PA address and even then only
	when your ISP has a single prefix.  For any other senario
	it is biased garbage.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 02 Jun 2008 16:06:53 +0200

Mark Andrews escribió:
> 	Section 6 Rule 9 is DESTINATION address selection.
so, are you suggesting to keep rule 8 of source address selection 
(longest prefix match) and remove rule 9 of destiantion address 
selection (longest prefix match)?

btw, an analysis of some multihomed scenarios and the impact of longest 
prefix match can be found at 
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-06.txt.

 From the draft, it is possible to see that it helps, but not that much 
and it is probably worth having better support. But i am not sure we 
should simply remvoe it with an errata. IMHO, we should actually solve 
this problem and provide a solution for multiprefixed sites

regards, marcelo
>   It
>> ------------------------------------------------------------------------
>>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Jun 2008 00:24:42 +1000

> this problem and provide a solution for multiprefixed sites

	I'm all for solving the real problem.  Longest match isn't
	the solution.  It only helps if you have a PA address and
	one of the destinations has the same ISP.  For all other
	cases it introduces a bias that has no science about it.
	In otherwords it introduces bias in 99.99999% of cases.
	It helps in 0.00001% of cases (and this is a generous estimate).

	Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Jun 2008 09:24:32 +1200

Mark,

Firstly let me say +1 to the view that this is absolutely not
suitable for handing as an erratum; I'm quite sure it was a
consensus decision of the WG.

Secondly, I am a bit surprised that it's written to apply to
IPv4 - that does seem inappropriate. My comments below are
applicable to IPv6.

On 2008-06-03 02:24, Mark Andrews wrote:
>> Mark Andrews escribi�:
> 	one of the destinations has the same ISP.

Which is, I think, why it's the second-to-last rule. However, it
also helps if one of the prefixes is the local ULA; since we don't
want to code address semantics when we can avoid it, it is the best
way to ensure that ULA addresses are preferred for internal traffic.

>       For all other

In IPv4 that may be so. In the IPv6 model, which is still PA-based
and multiprefix, it's far from true.

BTW, the text also says:

  "Rules 9 and 10 may be superseded if the implementation has other
   means of sorting destination addresses."

Regardless, IMHO, the way to deal with this is via WG debate on
the draft Marcelo mentions.

   Brian

>>>> Mark Andrews escribi�:

---

From: Tony Finch <[email-masked]>
Date: Mon, 2 Jun 2008 22:52:50 +0100

> 	traffic on particular address rather than spreading load.

And it has caused problems in practice. I tried to start a discussion
about this in December last year. Here are links to the first messages in
the threads on the apps-discuss and dnsop lists.

http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html
http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES BAILEY: SOUTHEASTERLY BECOMING CYCLONIC OR SOUTHWESTERLY 4,
INCREASING 5 TO 7. MODERATE, OCCASIONALLY ROUGH LATER. RAIN OR SHOWERS.
MODERATE OR GOOD, OCCASIONALLY POOR.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Jun 2008 10:03:35 +1000

> >> Mark Andrews escribi=EF=BF=BD:
> >>>> Well, longest prefix match is kind of useful in some scenarios i thi=
> nk.
> >>>>
> >>>> Imagine a site that is multihomed to two ISPs and has two PA address=
>  block
> >> s.
> >>>> Now, longest prefix match ensures that when a node of the multihomed=
> =20
> >>>> site wants to contact any other customer of its own isps, it does=20
> >>>> perform the correct source address selection and that is likely to b=
> e=20
> >>>> critical for the communication to work, especially if the isps are d=
> oing=20
> >>>> ingress filtering (i am assuming that the intra site routing of the =
> 
> >>>> multihomed site will preffer the route through the ISP that owns the=
> =20
> >>>> Even though this is one case and the problem is more general, i tend=
>  to=20
> >>>> think that this is an importnat case and things would break more if =
> this=20
> >>>> rule didn't exist
> >>>>
> >>>> Regards, marcelo
> >>>>    =20
> >> so, are you suggesting to keep rule 8 of source address selection=20
> >> (longest prefix match) and remove rule 9 of destiantion address=20
> >> btw, an analysis of some multihomed scenarios and the impact of longes=
> t=20
> >> prefix match can be found at=20
> >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-06=
> =2Etxt.
> >>
> >>  From the draft, it is possible to see that it helps, but not that muc=
> h=20
> >> and it is probably worth having better support. But i am not sure we=20
> >> should simply remvoe it with an errata. IMHO, we should actually solve=
> =20
> >=20

	It's wrong on a global perspective.  It's wrong on a intra-site
	perspective.  For PA you want to get into bands that a are
	multi-bit wide.  e.g.  /20-/47, /48-/63, /64-/128.

	longest match does nothing to help selecting between ISP's that are
	not in common with you.
	longest match does nothing to help intra ISP.
	longest match does nothing to help intra-site.
	longest match does nothing to help on the link.

	It has negative impacts in all the above situations as address
	which should be treated as equal no longer are.

	longest match does a crude approximation of the band selection
	above and also has negative consequences when is doesn't
	discriminate between the bands.
 
> >=20
> >=20
> >=20
> >>> =20
> >>>  =20
> >>>> Mark Andrews escribi=EF=BF=BD:
> >>>>    =20
> >>>>>  =20
> >>>>>      =20
> >>>>    =20
> >>>> --------------------------------------------------------------------=
> ----
>

---

From: Leo Vegoda <[email-masked]>
Date: Mon, 2 Jun 2008 23:25:40 -0700

On 02/06/2008 11:24, "Brian E Carpenter" <[email-masked]>

[...]

> and multiprefix, it's far from true.

I'm not sure that the reality of IPv6 prefix distribution is that it is
PA-based. A quick look at the statistics published by AfriNIC, APNIC, ARIN
and LACNIC (RIPE doesn't have a PIv6 policy yet) shows that about 1000
prefixes are /32 or shorter while about 275 are /40 or longer.

Of course, the IPv6 PI policies are all quite new and it could be there
there is very limited demand for IPv6 PI space with most people preferring
multiple PA prefixes but I doubt that's the case.

Regards,

Leo Vegoda

---

From: Thomas Narten <[email-masked]>
Date: Tue, 03 Jun 2008 08:43:40 -0400

Longest match in 3484 is a hack, ant it only works some of the
time. The WG most certinaly knew this when we approved the
document. But it was felt that longest-match was better than no rule
at all, as it helped on some situations.

The real discussion that should be held is what could we replace it
with if we pulled out the rule entirely?

We do need something better. What would that be?

Thomas

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Jun 2008 14:50:14 +0200

> We do need something better. What would that be?

I suggest to describe the longest match as a rule that can be used some
of time, and describe a new rule, random selection, to be used some of
the time.  Then you recommend the latter approach when the application
don't know that the longest match rule is more appropriate.

This would seem to meet the objective of causing the least surprise and
the least damage.

Thanks,
Simon

---

From: Ralph Droms <[email-masked]>
Date: Tue, 3 Jun 2008 09:01:33 -0400

Without some way to choose which rule to use and when to use it, how  
can a recommendation that has conditional rule usage be implemented?

- Ralph

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Jun 2008 15:27:36 +0200

> can a recommendation that has conditional rule usage be implemented?

We could detail the method to establish which rule to use, but that
requires that we can get consensus on those details.

Many people seems to prefer random selection.  Could those who prefer
longest match perhaps explain when that rule is appropriate to use and
preferable to random selection?  If so, we can use their explanation to
decide when to use that mode.  If that explanation doesn't apply to a
particular implementation, or the application does not know whether it
applies, using random selection could be the default.

/Simon

---

From: Tony Finch <[email-masked]>
Date: Tue, 3 Jun 2008 14:32:23 +0100

> can a recommendation that has conditional rule usage be implemented?

The Kame/BSD IPv6 stack has a system-wide address selection policy.
http://www.freebsd.org/cgi/man.cgi?query=ip6addrctl
If none is configured (which is the default) then the addresses from
the resolver are not re-ordered.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: WEST BACKING SOUTH 4 OR 5, OCCASIONALLY 6. SLIGHT OR MODERATE. RAIN
LATER. MODERATE OR GOOD, OCCASIONALLY POOR LATER.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Jun 2008 15:35:36 +0200

In case people want to read up on some of the history, here are some
links to earlier discussions for the Debian and GNU implementation of
the document.  GNU Libc actually implements a different section 6 rule
9, see 'The IPv6 Problem' in the second link below.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438179
http://people.redhat.com/drepper/linux-rfc3484.html

/Simon

---

From: "Arifumi Matsumoto" <[email-masked]>
Date: Tue, 3 Jun 2008 23:43:26 +0900

Hi all,

2008/6/2 marcelo bagnulo braun <[email-masked]>:
...
> this problem and provide a solution for multiprefixed sites

I'm one of the authors of the above mentioned draft.
This draft shows the problematic cases with the default address selection
rules defined in RFC 3484. Some of them are resulted from the longest
matching rule. So, I don't feel comfortable to see the above sentence
telling that this draft supports the longest matching rule.

IMHO, the longest matching rule should be deleted from IPv4 and IPv6
in order to preserve the DNS Round-Robin mechanism. Or, at least,
this rule should be configurable and should be off by default.
Now that the DNS RR is widely used and IPv6 hierarchical address allocation
is spoiled, we don't have a reasonable excuse for keeping the rule 9.

DNS RR cannot be implemented without the universal address selection
behavior. However, local optimization of traffic engineering owing to dst
and src address selection can be implemented locally, for example, by
manipulating the address selection policy table. The automization of this
manipulation process is the motivation for our proposal:
http://www.watersprings.org/pub/id/draft-fujisaki-dhc-addr-select-opt-05.txt
which is currently expired, though.

I have another expired draft:
http://www.watersprings.org/pub/id/draft-arifumi-ipv6-rfc3484-revise-00.txt
I'll include this issue of rule 9 in this draft and post it to 6man sooner.

Kindest regards,

Arifumi Matsumoto

---

From: Michael StJohns <[email-masked]>
Date: Tue, 03 Jun 2008 11:10:54 -0400

Can I suggest this discussion be transferred off the main list and to either the 6man list or the v6opts list (or both) please?  

Thanks - Mike

---

From: Tony Finch <[email-masked]>
Date: Tue, 3 Jun 2008 17:39:55 +0100

On Tue, 3 Jun 2008, Michael StJohns wrote:

> Can I suggest this discussion be transferred off the main list and to
> either the 6man list or the v6opts list (or both) please?

It causes operational problems for IPv4 too.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
WIGHT PORTLAND: NORTHWEST BACKING SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST.
SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Michael StJohns <[email-masked]>
Date: Tue, 03 Jun 2008 13:25:53 -0400

The particular document at issue is "Default Address Selection for IP version 6".  If you want to raise a similar issue for IPv4, I'm sure that there is an appropriate WG list for that as well.

---

From: Tony Finch <[email-masked]>
Date: Tue, 3 Jun 2008 18:37:35 +0100

On Tue, 3 Jun 2008, Michael StJohns wrote:

> The particular document at issue is "Default Address Selection for IP
> version 6".  If you want to raise a similar issue for IPv4, I'm sure
> that there is an appropriate WG list for that as well.

The RFC covers IPv4 too, as it says in the abstract.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: WESTERLY BACKING SOUTHERLY 4 OR 5, OCCASIONALLY 6 IN SOUTH. SLIGHT
OR MODERATE. RAIN LATER. MODERATE OR GOOD, OCCASIONALLY POOR LATER.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jun 2008 09:37:28 +1200

Leo,

...
> prefixes are /32 or shorter while about 275 are /40 or longer.

I don't deny that some registries have started allocating PI prefixes
for large sites. That doesn't make PI the default model for small and
medium multi-homed IPv6 sites, which is where our scaling problem will
lie.

I agree with Mike St Johns that this should be discussed on IPv6 lists,
except for the uncomfortable fact that RFC 3484 makes recommendations
for IPv4 too. Maybe the Internet Area can consider that aspect?

    Brian

---

From: Joe Abley <[email-masked]>
Date: Tue, 3 Jun 2008 23:06:45 -0400

On 3 Jun 2008, at 17:37, Brian E Carpenter wrote:

> for large sites.

ARIN is one such registry.

   http://www.arin.net/policy/nrpm.html#six58

All you need to do to qualify for a direct IPv6 assignment from ARIN  
is to not be an IPv6 LIR, and to qualify for any IPv4 assignment. The  
minimum assignment in such cases is a /48.

   http://www.arin.net/policy/nrpm.html#four3

All you need to do to qualify for a direct IPv4 assignment from ARIN  
is to demonstrate an intent to be multi-homed. The minimum assignment  
in such cases is a /22. End users need to demonstrate an immediate  
need for a /24, and a projected need for a /23 within a year.

> That doesn't make PI the default model for small and

Per above, if you're multi-homed and can justify a /22 of IPv4 space,  
you can get a /48 of IPv6 space as a direct assignment. You can  
qualify for the /22 if you plan to need a /23 within a year. I would  
say that a site that could number its entire operation in an IPv4 /23  
could reasonably be called "small". Note that there is no requirement  
in the policy to use NAT or RFC1918 addresses.

It seems to me that direct assignment could quite possibly become the  
default for small IPv6 sites in the ARIN region. IPv6 uptake to date  
has been so tiny that I don't think anybody can predict what  
behaviours will become prevalent if/when IPv6 takes off.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jun 2008 16:20:50 +1200

Joe,

> default for small IPv6 sites in the ARIN region. IPv6 uptake to date has
> been so tiny that I don't think anybody can predict what behaviours will
> become prevalent if/when IPv6 takes off.

We can't predict how economic actors will choose to act. What we can predict
is catastrophe if ten or 100 million sites attempt to push /48 advertisements
out into BGP4. It would be highly irresponsible of any registry to pursue
a policy that leads to such a result, until we have a technical solution
to the resulting scaling problem. It's exactly because we don't have such
a solution that the IPv6 design model is PA.

I'm not shocked at the notion of a few hundred thousand early adopters of
IPv6 getting PI prefixes. But that's a very different matter than millions.

(This remains directly relevant to the subject of this thread. The
infamous Rule 9 exists, right or wrong, because of PA addressing
in IPv6.)

    Brian