Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt

From: Dan Lanciani <[email-masked]>
Date: Sat, 4 Dec 2004 03:10:05 -0500 (EST)

Mark Andrews <[email-masked]> wrote:

|> Mark Andrews <[email-masked]> wrote:
|> 
|> |> Mark Andrews <[email-masked]> wrote:
|> |> 
|> |> |> Mark Andrews <[email-masked]> wrote:
|> |> |> 
|> |> |> |+    Advertising locally assigned ULA AAAA records in the global DNS i
|> s
|> |> |> |+    MUST NOT occur as they are not globally unique and will lead
|> |> |> |+    to unexpected connections.
|> |> |> 
|> |> |> I strongly object to making this a "MUST NOT," especially with the grow
|> ing
|> |> |> uncertainty that there will ever be a _permanent_ centrally assigned fl
|> avo
|> |> r
|> |> |> of ULA available without recurring fees.
|> |> |
|> |> |	Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG.
|> |> 
|> |> Wrong in what way?  Morally?  If you don't want to be troubled by the
|> |> presence of locally assinged ULAs in my forward DNS, just don't request
|> |> names from my forward DNS.
|> |
|> |	A host may have *both* a LOCALLY ASSIGNED ULA and a global
|> |	addresses.  In fact this is highly likely.  If I have a
|> |	machine withe the same ULA when I attempt to connect the
|> |	remote machine I will get my machine according to the address
|> |	selection rules.
|> 
|> This may be true, but it is not responsive in spite of the tasteful use of
|> ALL CAPS.  You are starting with the premise that you are attempting to
|> access my machines by looking up a name in my DNS.  If you don't like the
|> way I populate my DNS then you don't need to use my DNS.
|
|	If it in the global DNS is in NOT "your DNS".  It is everybodies.

What are you talking about?  The data in my DNS resides in my servers or
in servers that I contract to hold it.  You don't see it unless you query
those servers.

|	If you want to put it in your DNS then use split DNS.   Stop
|	polluting the commons.

This is not a commons issue.  Stop trying to assert jurisdiction over my
property.

|> |> |	If you need to publish them in the DNS you need to use a 
|> |> |	split DNS configuration.
|> |> 
|> |> No, that will not work if I want to use locally assigned ULA addresses for
|> |> dynamic tunnels that anyone can access.  And in any case, do you really wa
|> nt
|> |> us to be in a position of mandating split DNS?  I have no objection to fol
|> ks
|> |> running split DNS if they so desire, but I do not so desire and I certainl
|> y
|> |> do not wish to force split DNS on anyone.
|> |
|> |	Then choose a centrally assigned ULA.
|> 
|> As I'm sure you are aware, centrally assigned ULAs are not currently availabl
|> e
|> and their future availability on the terms originally suggested is becoming
|> increasingly unlikely.
|
|	Centrally assigned ULAs will appear.

I never said that they will not, only that it is unlikely that they will
exist on the terms originally suggested in discussion by this working group.

|> |The two types of ULA have
|> |	different usage patterns.  Pick the correct one for the job.
|> 
|> When the proposal to create ULAs was "split" in order to accommodate a longer
|> process for the centrally assigned flavor (because of the supposed need for
|> comments from the existing address registries) the locally assigned flavor
|> had the necessary attributes to support a wide variety of usage patterns.
|> You propose to restrict the usage of the locally assigned flavor in such a
|> way that many interesting applications will demand the centrally assigned
|> flavor.  I propose that if we really want to do that then we should first
|> insure that the centrally assigned flavor comes into existence on reasonable
|> terms.

I see that you again declined to respond to my proposal that we first insure
that the centrally assigned ULAs come into existence on reasonable terms.

|> |> |This is no different to how we handle
|> |> |	RFS 1918 address.
|> |> 
|> |> Umm, if locally assigned ULA addresses are going to have to be treated the
|> |> same as RFC1918 addresses, why couldn't we have just kept site local addre
|> sse
|> |> s?
|> |
|> |	Centrally assigned ULAs are globally unique.  The restiction if
|> |	you read what was written above was on LOCALLY ASSIGNED ULAs.
|> 
|> And if you read what I wrote above you will see that I was indeed speaking
|> of locally assigned ULAs, even though I didn't put it IN ALL CAPS.
|>
|> |	There is a choice.  You choose which set of tradeoffs to apply
|> |	when select your ULA.  You could even have one of each type.
|> 
|> This is a false choice.  It is impossible to choose the set of tradeoffs
|> because we have no idea what the attributes of centrally assigned ULAs (if
|> they ever exist at all) will be.  Basically, we copped out on mandating the
|> critical attributes of centrally assigned ULAs (permanent assignment, low
|> one-time fee) yet now you want to mandate restrictions on locally assigned
|> ULAs that will force a requirement for the centrally assigned flavor.
|
|	You believe permanent assignment, low one-time fee was manditory.

In as much as those attributes were core to the original proposal, yes.  But
that is irrelevant to the impossibility of examining tradeoffs when we have
no idea what the attributes of centrally assigned ULAs will be.  It is rash
to use the assumption that there will be useful choices in the future to
restrict choices today.

|	I never did.  The *only* thing critical about centrally assigned
|	addresses is that that are uniquely assigned within the specified
|	address range.

But uniquely assigned addresses are already available.  They are expensive
and they are not permanent.  Do you really expect anyone to believe that
you thought that the sole purpose of the centrally assigned ULA proposal
was to create a new numerical range with no specific allocation attributes?
Either you totally missed the point or else you are arguing so disingenuously
that progress is impossible.

|The rest is just nice to have.  If the registries
|	charge too much then people will move to locally assigned ULA and
|	live with the limitations imposed by those addresses.

That answer was acceptable before you proposed to impose such a severe
restriction on locally assigned ULAs.

|> |> |They don't get published in the GLOBAL DNS
|> |> |	because they are AMBIGIOUS.
|> |> 
|> |> Merely repeating this assertion (even IN ALL CAPS) really isn't a useful
|> |> argument.  We have spent many months discussing ULAs as a solution to the
|> |> ambiguity of site local addresses.  This seems like a last minute attempt
|> |> to cripple them.
|> |
|> |	No.  It is a attempt to prevent harm from incorrect use.
|> 
|> Harm to whom?
|
|	Harm to users of the DNS.

Again, nobody forces you to use the DNS of a publisher of locally
assigned ULAs.

|RFC 1535 was written in response to
|	resolvers return address which connected to the wrong machines
|	when putting in fully qualified addresses.  You are asking
|	the WG to endore a similar policy because you believe centrally
|	assigned addresses will never occur.

No, I'm asking the WG to wait until centrally assigned addresses exist before
effectively crippling locally assigned ULAs.  But for the record I do not
accept your premise that any small chance of ambiguity is euqally objectionable
to an almost guaranteed ambiguity.

|> |> |> An important feature of even locally assigned ULAs is that they are glo
|> bal
|> |> ly
|> |> |> unique "enough" for many/most purposes that have been discussed.  After
|>  mo
|> |> nth
|> |> |> s
|> |> |> of analysis to that end, their lack of absolute uniqueness is insuffici
|> ent
|> |>  to
|> |> |> justify adding new prohibition on a particular range of uses at this la
|> te 
|> |> dat
|> |> |> e.
|> |> |
|> |> |	They are unique enough to link serveral hundred / thousand sites
|> |> |	*with minimal renumbering required*.
|> |> |
|> |> |	They are not unique enough to link millions of sites where the
|> |> |	is no way of knowing that renumbering is required.
|> |> 
|> |> Even if you are correct that they are not unique enough to link millions
|> |> of sites (and I do not accept that you are correct--duplicates could be
|> |> handled by cooperating sites by a de facto uniqueness mechanism outside
|> |> the scope of this proposal) how does this justify restricting the utility
|> |> of locally assigned ULAs in the several hundred/thousand sites case?
|> |> 
|> |> How about a compromise?  Let's first insure that centrally assigned ULAs
|> |> are available for permanent assignment with no recurring fees (and at most
|> |> a nominal initial fee).  Once that is accomplished we would be in a better
|> |> position to weigh the costs/benefits of recommending locally assigned ULAs
|> |> in various contexts.  Such recommendations could be in a document separate
|> |> from the core ULA document.  Restricting the use of locally assigned ULAs
|> |> before we even know whether there will be an alternative seems a bit rash.
|> |> After all, this topic has been under discussion for a very long time; what
|> 's
|> |> the rush now?
|> 
|> I see that you declined to reply to my suggested compromise.  How about we
|> make centrally assigned ULAs work before we break locally assigned ULAs?
|> 
|> |	It's not rash.  They have limitations.
|> 
|> You are confusing architectural limitations with administrative restrictions.
|> The architectural limitation of locally assigned ULAs is that there is some
|> chance of duplication.  This implies that exposure of such addresses outside
|> of the realm in which their uniqueness can be guaranteed may lead to ambiguit
|> y.
|> This is true regardless of the mechanism used to expose those addresses: glob
|> al
|> DNS, some other name lookup system, or even the passing of a literal address
|> in some random protocol.
|> 
|> Your proposal to prohibit locally assigned ULAs from the global DNS is an
|> administrative restriction--one which considerably devalues the addresses
|> in question.
|
|	They were already devalued.  It was inherent consequence of the
|	assignment technique.  You must be the only one who thought that
|	publishing of locally assigned ULA in the global DNS was going to
|	occur.

Actually, I never expected any kind of useful ULAs to exist at all.  I
expected pretty much the kind of two-pronged attack we are seeing.  First
turn the centrally assigned ULAs into rentals like the rest of the global
space and then restrict the locally assigned ULAs to the point where they
are unusable.

|I know from the start as should have anyone who has
|	ever dealt with site locals / link local / RFC 1918 addresses that
|	there were never going to be published in the global DNS.  They
|	were by ther very nature abmigious.
|
|	The fact that I said MUST NOT should not have come as suprise to
|	anyone here.

Well, it comes as no surprise to me because of my cynical assessment of the
entire site local "replacement" plan.  I would think it might come as a
surprise to folks who believed that they might really get some useful stable
address space out of this proposal.

|	Sure the addresses will leak from time to time.  You don't however
|	deliberately *publish* them however.
| 
|> |The fact that you
|> |	don't like the limitatitions does not mean that they should
|> |	not be acknowledged and dealt with appropriately.
|> 
|> The limitations of locally assigned ULAs have been acknowledged and discussed
|> extensively.  Your proposal to create an administrative restriction does
|> nothing to deal with the limitations; it merely forces the use of an as yet
|> undefined alternative where locally assigned ULAs would have been sufficient.
|> This is very reminiscent of the original site local debates.
|
|	Site local was much worse.  Here you choose which type of address to
|	use.

No, you misunderstand.  I was comparing the form of the debates, not the
addresses.  We were perpetually promised that once we got rid of site locals
we could have something better, though as yet unspecified.  Now we almost
have locally assigned ULAs which--if not burdened with various administrative
restrictions--might just be better.  You propose to kill those for anyone not
willing to use split DNS, and instead require centrally assigned ULAs which are
conveniently stuck in limbo waiting for the existing registries to figure out
how much they will cost.  It's interesting that you waited until well after
the central/local division (not to mention well after the original extended
discussions) to start insisting on the addition of your DNS restriction.

In any case, I will have to leave it to others to further this thread--if
indeed anyone cares to do so.  Please feel free to have the last word.

				Dan Lanciani
				ddl@danlan.*com

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 4 Dec 2004 06:29:31 -0600

Thus spake "Dan Lanciani" <[email-masked]>
> This is not a commons issue.  Stop trying to assert jurisdiction over my

This has practical ramifications too; it's not possible to prevent people 
from putting ULAs in the global DNS since each controls their own zones. 
Anything we put in the i-d will be advisory in practice, so a SHOULD NOT is 
more appropriate than a MUST NOT even if we hypothetically agreed that it's 
a bad idea.

I'll note that RFC 1918 says ambiguous addresses "should not" be seen 
outside their realm of validity.  There is no reason to put a stronger 
restriction on ULAs, which have a significantly lower chance of actually 
being ambiguous in practice.

> that the centrally assigned ULAs come into existence on reasonable terms.

Locally-assigned ULAs should be significantly easier to get in place than 
centrally-assigned ULAs, and IMHO it is prudent for us to make sure the 
former will have no deficiencies compared to the latter other than the 
possibility of collisions.

> to use the assumption that there will be useful choices in the future to

Agreed.  For now, we must treat locally-assigned ULAs as if they're all 
we're going to get.

> Again, nobody forces you to use the DNS of a publisher of locally

Publishing an unreachable or possibly-ambiguous address in DNS hardly 
constitutes harm.

> to an almost guaranteed ambiguity.

Ditto.  If the odds of collision are considered significant enough that we 
need to start treating ULAs as ambiguous, we need to revisit how many random 
bits there are or how they're generated.  If we end up treating ULAs as if 
they're ambiguous, then we've made little or no progress versus site-locals.

> space and then restrict the locally assigned ULAs to the point where they

IIRC, I'm the one who originally suggested ULAs be allowed in the global 
DNS, and after a brief discussion it appeared to have consensus.  I don't 
recall any of the current debate coming up back at that time.

> address space out of this proposal.

MUST NOT certainly comes as a surprise to me.  There was a very specific 
reason I proposed that ULAs be allowed in the global DNS even if I didn't 
want them to be _common_, and the current "not recommended" is sufficient. 
Maybe we should upgrade that to SHOULD NOT, but not to MUST NOT.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Mark Andrews <[email-masked]>
Date: Sun, 05 Dec 2004 09:45:39 +1100

If ISC was to publish in the DNS

	www.isc.org.            10M IN AAAA     2001:4f8:0:2::d ; exists today
	www.isc.org.            10M IN AAAA     FC01:4f8:0:2::d

	and you happened to have a machine with local addresses
	FC01:4f8:0:2::d.

	You would be unable to reach www.isc.org from any machine
	receiving your ULA prefix as a consequence of the address
	selection rules.

	This is the harm that can be caused when you publish a
	LA ULA.

	If you don't have MUST NOT you don't have a way to point
	blame when things go wrong.  With MUST NOT you can say
	please remove the address you are in violation of RFC XXXX.

	2001:4f8:0:2::d is assigned by forcing the LL address then
	using auto assignment to get the other prefixes.  It is
	done this way so it won't change with hardware changes.

	I expect other sites will do similar things to provide stable
	addressing to their external machines.  Collisions in addresses
	get much more probable when you start assigning the local parts
	by hand.

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

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 4 Dec 2004 23:34:20 -0600

Thus spake "Mark Andrews" <[email-masked]>
> receiving your ULA prefix as a consequence of the address

I can't ping that same host with "ping fc01:4f8:0:2::d" either; whether the 
hostname is in DNS or not doesn't materially reduce the impact of a LA ULA 
collision.

> This is the harm that can be caused when you publish a

That is certainly a possible outcome if you happen to collide with someone, 
that someone happens to be mixing PI/PA and LA ULA addresses for a given 
hostname, and you happen to try to contact a host via that hostname.  Care 
to calculate the odds that your scenario will happen?

However, there do exist cases where the behavior is well-defined and correct 
even in the face of ambiguity.  Suppose you have:

www-dev.isc.org.            10M IN AAAA     fc01:4f8:0:2::d ;no PI/PA addys

which is (hypothetically) a development server only intended to be used by 
ISC's business partners, and ISC's LA ULA prefix is reachable over private 
links within the closed set of parties that need to use the dev server.

ISC's business partners can reach the dev server at the above name with no 
changes to their local nameservers (if they even have control of such), 
removing an opportunity for human error to intrude.  OTOH, anyone else 
trying to contact the dev server will either reach a different host (due to 
a collision) or nothing at all -- either is acceptable to ISC.  The hostname 
and IP are intended to be useless to any party not privately connected, 
whether colliding or not, and a LA ULA is no worse as a public response 
than, say, an address assigned to a competitor: neither is valid data yet 
neither is a protocol or logic violation.

> please remove the address you are in violation of RFC XXXX.

from RFC 2119:
"SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."

That sums up exactly how putting LA ULAs into the global DNS should be 
viewed: there exist circumstances when doing so is useful, but they require 
careful thought to prevemt unintended interactions.  The LA ULA draft could 
certainly be enhanced with a list of what to consider and example scenarios 
where they do and don't work, but a MUST NOT isn't appropriate as long as 
there is _any_ legitimate use.

Removing the LA ULA from DNS will not solve the ambiguity problem anyway, 
nor does it mask the interaction with address selection rules.  The problem 
still exists at the IP layer, and any application that supports IPv6 address 
literals (i.e. nearly all of them) would see the exact same behavior if 
users were to type in an ambiguous ULA literal instead of a hostname that 
resolved to that ULA.  Should we also ban users from distributing LA ULAs 
via smoke signals or avian carriers to keep from trying to use addresses 
where they're not valid?

Finally, the verbage may give you something to point at when another admin 
does something you don't like, but that's the _only_ effect it will have. 
If he's going to ignore a MUST NOT in an RFC, what are the odds he'll make 
non-trivial changes to his configuration merely because _you_ had the 
misfortune to collide with his prefix?  Of course, the only serious risk of 
collisions will be from intentional failure by both parties to follow the 
MUSTs in the draft...

> get much more probable when you start assigning the local parts

It reduces the collision space from 2^128 to 2^64, which is significant, but 
LA ULA prefixes are sufficiently unique that the rest of the address doesn't 
need to be.  With 40 bits, we'll need over a million sites fully 
interconnected using LA ULAs before there's a 50/50 chance of prefix 
collision...  Of course, since ULAs' scope is expected to be from one to a 
few thousand sites, making the odds of collision on the order of 2^-15 to 
2^-40 for each ULA prefix.  It is safe for us to act as if LA ULAs were 
unambiguous and let layer 8 detect and correct collisions if they ever 
occur.

Now consider the odds of a human error at a registry that results in a 
duplicate assignment; since it's nonzero (provable, since it's happened to 
me) should we also start treating PI/PA space as ambiguous just in case? 
No, we act as if PI/PA space were unambiguous and let layer 8 detect and 
correct duplicates when they occur.  Notice the symmetry there?

In the end, the entire DNS paragraph is totally unenforceable thus the 
choice of SHOULD NOT or MUST NOT is not going to change a darn thing in real 
deployments.  Consensus was achieved on this point long ago, and there is no 
indication that has changed or that it would make a meaningful difference 
even if it had.  This effort would be better spent on other parts of this 
draft or on building support for CA ULAs and/or end-user PI space.

S

---

From: Mark Andrews <[email-masked]>
Date: Sun, 05 Dec 2004 17:53:51 +1100

> neither is a protocol or logic violation.

	If you want to be able to do this then get a CAULA.  CAULA are
	designed for those who want to play on the global scale.  Use the
	right tool for the right job.  Stop trying to treat CLULAs as if
	they are identical to CAULAs.  They aren't.
 
>    before implementing any behavior described with this label."

	This WG has much too little experience with DNS administators.
	You give them a inch with a SHOULD / SHOULD NOT and they take
	a mile.

	DNS/TCP is a SHOULD in RFC 103[45].  Care to hazard what
	one of the major probems is with the DNS?  TCP being blocked
	at the firewall, one vendor doesn't support TCP by default.

	I don't know how many times I've heard "Oh DNS/TCP is a SHOULD
	we don't need to support it." even when the DNS lookups against
	their servers are failing because they have DNS/TCP blocked.

	This section really is targeting DNS administators.  If they can
	make a wrong decision with a SHOULD / MAY they will.  10+ years
	of correcting mistakes like this has shown me that you don't
	leave doors like this open.

	This will become "It's only a SHOULD NOT it won't cause any harm".

	DNS administators regularly fail to keep the parent/child NS records
	in sync.  They regularly only put glue in the parent zone.  These
	are the basics.

	You want to hand them a SHOULD NOT.

> there is _any_ legitimate use.

	CAULA in the global DNS will result in unreachable machines.

	LAULA in the global DNS will result in connections to wrong
	machines with subsequent exposure of everything transmitted over
	those connections.

> via smoke signals or avian carriers to keep from trying to use addresses 

	I never said it would remove the problem.  It will however prevent
	part of the set of problems caused by having ambigious addresses.
	Remember when a user types in a LAULA they know (can know) they have
	hace a LACULA.  When a user types a domainname into a application
	they have no way of knowing that they have got back a LACLA.

	I know when a type 10.x.x.x that it is ambigious address.  Users
	will learn that FC... is a ambigious address.

	I didn't say don't put them in the DNS.  I said don't put them in
	the global DNS.
 
> collisions will be from intentional failure by both parties to follow the 

	It's much easier to get change when it is clearly proscribed.
 
> unambiguous and let layer 8 detect and correct collisions if they ever 

	We are talking aboult LAULA's assigned world wide.  Not just the
	number of LAULA within a private routing domain.

> correct duplicates when they occur.  Notice the symmetry there?

	Putting LACLA into the DNS results in "broken by design".  This
	is very different to "broken by error".
 
> draft or on building support for CA ULAs and/or end-user PI space.

	Pointing out the limitations of LAULAs actually enhances
	the need for CAULAs.  By attempting to treat them the same
	you actually are saying "we don't need CAULAs.  LAULAs are
	`good enough' for everything we want to do."

	They clear are not good enough for every senario.  Pointing
	out the differences make the case for both types stronger,
	not weaker.  Letting people know up front the inherent
	limitations of each type is a good thing.

	I want CAULAs.  I'd even be willing to pay a reasonable
	annual fee.  If I can't get get a CAULA at a reasonable fee
	I will use a LAULA and live with the limitations that it
	brings.

	Mark

---

From: Daniel Senie <[email-masked]>
Date: Mon, 06 Dec 2004 03:34:33 -0500

>         receiving your ULA prefix as a consequence of the address

Come on. This is NOT a real-world example.

Today, I publish domains of the style example.com for production (public) 
use. I also publish NS records for zones of the style local.example.com for 
addresses on local (i.e. PRIVATE) networks that are not reachable from 
outside. Why do I do this? It simplifies getting around on private networks 
that allow servers to communicate for private matters (backups, for 
example). The servers are multihomed, with a public facing interface that 
is used for public things and a private-facing interface that's used for 
private things.

There's no interference with public operations. If you try to ping a host 
on .local.amaranth.net, you may get unexpected results since there are many 
RFC1918 addresses there. Did this harm anything? No. Could I use views in 
BIND to block your being able to query there? Sure.

People can and will publish zones for private use. Using a third level, 
such as local.example.com, is a GOOD way to do this.

If you're concerned about people screwing up in the form you show above, 
then make a statement to that effect, rather than insisting on a MUST NOT 
that covers reasonable, and non-interfering usage such as folks have been 
using for years in IPv4. There's no Commons involved here.

>         please remove the address you are in violation of RFC XXXX.

That's worked exceptionally well for folks leaking bogus-sourced packets 
(RFC 2827/BCP38). The IETF doesn't have a very good police force. If your 
goal is to enforce this by making DNS server products refuse to load zone 
data containing ULAs, I suspect that will fail as well, as the marketplace 
will insist such be allowed, and some vendor(s) will ignore claims to the 
contrary in the RFC.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Dec 2004 20:25:46 +1100

> BIND to block your being able to query there? Sure.

	It does no harm unless someone happens to attempt to use
	those names outside of your world.  You have no knowledge
	of what is running on those addresses.

	Internal email address do leak.  The safe response to a
	leaked internal address is to have it not connect to anything
	when used externally.  Your decision causes harm when the
	address is actually running a SMTP server.

	Similar senarios happen with every other protocol.

	Because the addresses are ambigious you have no knowledge
	of what harm a name leak will cause.  You think that is
	harmless.  You can't know for sure what the impact of a
	name leak will cause.

> using for years in IPv4. There's no Commons involved here.

	I say MUST NOT because you cannot, as the publisher,  know the impact
	of publishing a ambigious address has on others.
 
> will insist such be allowed, and some vendor(s) will ignore claims to the 

	Just because people don't do the right thing is not a reason to
	not tell them what the correct thing to do is.
	
	Mark