Subject: Another look at 6to4 (and other IPv6 transition issues)

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2011 11:55:18 -0400

Hi.

I've been thinking about this and having a few off-list
conversations and want to make a suggestion that draws together
a few others.  Since many people don't like my long notes with
the conclusion at the end, this one is suggestion-first.  If the
suggestion offends you sufficiently, you can just stop reading
there.

Recommendation:

(1) Abandon the effort to classify the specifications as
Historic.  It is at best a symbolic act that few people outside
the IETF community will even notice, much less act differently
because we have done it.  Instead, let's try to focus on what is
actually important, not classification and name-called ("curse
you, you Historic protocol" :-(  ).

(2) Pull the "-advice" document back from the RFC Editor queue
and fold the actual substantive content of the "-historic"
document into it, preferably as a very clear and very prominent
Applicability Statement.  If this is what v6ops believes, the
statement might reasonably say something like:

	(2a) This protocol, if not used very carefully, leads to
	bad operational situations in which things get lost and
	the problems are hard to diagnose.   We strongly
	recommend that it not ever be a default and that it not
	be used except under special circumstances and with
	great care.
	
	(2b) Even then, we recommend that it not be used unless
	all of those configuring routing information and all the
	systems along the routing path are run by experts who
	both understanding the issues and are willing to accept
	responsibility.
	
	(2c) If you do decide to use the thing, the "advice"
	recommendations in the rest of this document are
	mandatory and MUST be followed to avoid serious
	operational problems.

I haven't included either Randy's colorful language or mine in
the example above, but the intent should be clear.  Depending on
how much detail the community thinks is useful, there is a good
deal of potentially-useful text in draft-moore-6to4-experimental
as well as in the "-historic" draft.

The resulting document should explicitly update RFC3056 and
RFC3068.  Taking that action will send a much stronger "you need
to read that document before doing anything with this one"
message to most of the people who are familiar with how things
work than a reclassification of the base documents.  For those
who aren't familiar with how things work, all of these
approaches, including moving 6to4 to Historic, are pointless.

That is all.  This can and should be made to sound like mature
engineering advice, which it presumably is, and not like small
children throwing mud at each other.

Explanation and Rants:

(ii) I think moving _this_ protocol to Experimental is just
silly.  We use Experimental for things that are
pre-standardization or not sufficiently mature to be
standardized.  Although the bar is higher, there are elements of
"experiment" in every Proposed Standard --that is why we have a
multiple-step standardization process.   If there is really
something to be learned from 6to4 operated in a different way,
then the right action to take would be to propose a 6to4bis that
outlines the characteristics of the protocol, eliminates
anything we have concluded should not be done, and outlines the
desired experiment.  That document might reasonably be listed as
updating RFC3056 and RFC3068 as well.  

(i) <rant> Presumably our goal is to get IPv6 deployed and
provide advice useful to its deployment, independent of any
particular piece of protocol or transition arrangement.  At
least one of the many reasons we haven't seen more deployment is
that we keep sending messages to the broader community that,
however unintentionally, discourage that deployment.  In the
early days of IPv6, we did that by advertising (or letting
others who were presumed to be speaking for us advertise) that
IPv6 was completely ready and that transition was going to be
easy, cheap, and seamless.  For those who had to make decisions
as to when to deploy IPv6, sufficient investigation tp discover
that some of that story was untrue became sufficient motivation
to back away from IPv6 entirely until we got our acts together.
In more recent years, we have continued to deliver the message
that the IETF (and, to a lesser extent the RIRs) are simply
confused about what advice to give and therefore that IPv6 isn't
ready for someone to deploy who suffers from limited resources
and a strong desire to do it only when all of the ducks are
lined up.  Every time we propose a new transition model or
denounce an old one without what seems to be an
externally-convincing analysis of the complete picture, we make
things worse by distributing yet another chapter of "even the
IETF has no real idea how to transition to IPv6".

If we are serious about encouraging deployment of IPv6 -- and I
hope we are -- then it is time to stop the apparent war among
transition strategies.  It seems to me that the document that is
needed is a vastly strengthened (and probably standards-track)
version of RFC 6180 (a rather nice document that I would
encourage those who are engaged in the 6to4 debate on the IETF
list to read), but one that goes beyond such statements as 

	There are several types of tunneling mechanisms,
	including manually configured IPv6-over-IPv4 tunnels
	[RFC4213], 6to4 [RFC3056], automatic host-based tunnels
	[RFC4380], tunnel brokers [RFC3053], running IPv6 over
	MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798],
	the use of Virtual Private Networks (VPNs) or mobility
	tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454]
	[RFC5555] [RFC5844], and many others.

(from Section 4.2) and into a serious discussion of the
scenarios that are the best match to different of these
strategies (and others).  If we don't know, then let's say,
explicitly, that we haven't had quite enough experience to
provide a differential chart of when particular techniques can
be used but that they are out their, with their strengths and
weaknesses, for situations to which they seem well-adapted.  It
is almost possible to infer from 6180's conclusions that almost
all transition mechanisms are equivalent, at least within
groups, and those that aren't are best dealt with by public
burning.  Clearly we don't believe the first part of that; we
should get away from the appearance of believing the second.

And, again and most important, if we want to see IPv6 deployed,
we need a clear message that we actually understand what we are
doing, that we have a coherent picture, and that our process is
not one of lurching among solutions, hoping that each one will
be the magic bullet, and then denouncing any that turn out to
not have sufficient magical properties.  The marketplace knows
how to deal with the message we are sending with debates about
recategorization and we have already seen the answer: it isn't
the universal deployment of IPv6 before now or any time soon.
</rant>

    john

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Jul 2011 09:40:47 -0700

So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not.

On Jul 15, 2011, at 8:55 AM, John C Klensin wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2011 14:52:32 -0400

--On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli
<[email-masked]> wrote:

> So the rational for the advice document not being combined
> with the standards action in it is that the later has some
> polarizing impact, the advice document does not. the advice
> document is through and done, historic is not.

Joel (and others),

I understand the rationale.  At the risk of repeating myself, I
simply do not think it works or is appropriate.  Recategorizing
set of documents as "Historic" is an extremely blunt instrument.
If we do it in a consistent and logical fashion, the advice
document would have to go to Historic along with the base
documents because giving advice about a piece of ancient history
is meaningless.  That is not what most people who like the
advice document intended, at least as I understood the consensus
on that Last Call.

Worse, for those who are successfully operating 6to4 and finding
it useful, reclassifying the specifications to Historic sends a
clear message that, from their perspective at least, the IETF is
clueless (since "Historic" essentially says the thing is useless
and/or that no one is using it... and they know better because
they are a counterexample).   The consequence of that, in turn,
is that they either simply ignore the advice or conclude that
they should postpone IPv6 deployment until the IETF gives advice
that is both coherent and believable.

I think there are probably a dozen "right" ways to do this, with
the differences depending on issues that I haven't followed
v6ops or 6to4 deployment closely enough to have opinions about.
What they have in common is a real analysis of issues and some
meaningful recommendations ("-advice" seems to do much of that)
and the used of "updates" to effectively incorporate that advice
and guidance into the base spec.   If that is better done with a
standalone document that references the base spec and the advice
document, updating all of them, I'm fine with it (although,
under that scenario, I'd prefer to have the advice document on
standards track).   

Finally, if we had a wonderful transition model that would work
well in all situations, then it would make sense to recommend it
and depreciate everything else.   We don't.  What we have are a
bunch of mechanisms, each with advantages and disadvantages,
some much better adapted to particular situations than others.
It would be easier if we had a good single solution, but we
don't... that is life, or at least engineering.  Given that, we
serve the community much better with analyses and explanations
of tradeoffs (and RFC 6180 is, IMO, a really good start) than we
do by going through exercises of figuring out what to denounce.
IMO, the _only_ thing we should be categorically denouncing are
tactics and strategies that encourage people to put off getting
serious about IPv6.  Unfortunately, trying to slap a "Historic"
label on one particular transition strategy, or to rank
transition strategies that have proven useful to some actors on
the basis of how much various of us loathe them, are about
denunciation and, however unintentionally, with the risk of
encouraging people to sit and wait, not about progress or
network engineering.

back to lurking...
    john

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Jul 2011 12:17:08 -0700

On Jul 15, 2011, at 11:52 AM, John C Klensin wrote:

> simply do not think it works or is appropriate.

And there are people that disagree with you on that.

>  Recategorizing

<SNIP>

> and depreciate everything else.

You missed the boat about a decade back I guess. Transition technologies (none of them) are a substitute for actual deployment. They should naturally decline in popularity and in fact in the portions of the internet where we can measure them they are. Right now if we try and fit a story to the evidence that is happening because of host changes, and  not because of deployment. ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that.

>   We don't.  What we have are a

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Jul 2011 12:37:36 -0700

Hi Joel, 

> ipv4 is becoming less usable and it's 
> taking autotunnels with it, nobody here has a proposal that 
> changes that.

As far as I can tell, IPv4 is not becoming less
usable within my organization's network.

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Jul 2011 08:34:22 +1200

On 2011-07-16 03:55, John C Klensin wrote:

> Applicability Statement.  

I am very strongly against this. The advisory document received extremely
strong support and excellent technical input from a wide cross section
of the IPv-anything operational community and has been fully approved
and is ready to go. I originally hoped it could be published for
World IPv6 Day, but having missed that date, it remains urgent to get
it out there, and to publicise it to operators who are not aware
of the issues.

We can spend another few months debating the exact form of words for
a normative document advising implementors to do what most of them
are now doing; I don't care and it basically doesn't matter except
in the IETF's tiny world. That isn't what's important. What's
important is to get as many operators as possible doing what they
can to ameliorate the situation.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2011 17:01:30 -0400

--On Saturday, July 16, 2011 08:34 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> We can spend another few months debating the exact form of
> words for a normative document advising implementors to do
> what most of them are now doing; I don't care and it basically
> doesn't matter except in the IETF's tiny world. That isn't
> what's important. What's important is to get as many operators
> as possible doing what they can to ameliorate the situation.

Brian,

It seems to me that you can take two positions here, but not
both as the same time.

Position #1: What the IETF does, and how it classifies things,
actually make a difference.  If that is true then the advice
document should look a lot more mandatory and should certainly
be shown as updating the 6to4 base documents (I note that the
latter decision could be made without reopening the document in
any significant way).  Whether it is part of the advice document
or not, an applicability statement that discusses what is really
going on is important and reclassification to Historic would be
stupid.  If nothing else, unless it reclassifies your advice doc
to Historic as well, reclassification to Historic would be
appeal-bait.  And classifying your document as Historic also
would rather dilute the message.

Position #2: How the IETF classifies things makes very little
difference in this space because people will follow advice that
seems sensible and ignore everything else.  If so, it makes
little difference how your document is approved or where it is
published.  For example, it could have come through the
Independent Stream or been pushed into CCR.  No problem.  And
the "Historic" effort is a huge waste of the community's time,
no matter how it comes out.

Just my opinion -- you will probably continue to disagree.

best,
   john

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Jul 2011 15:43:12 -0400

> usable within my organization's network.

You realize that you have not contradicted what Joel said, right?     The IETF's business isn't making sure that Boeing's networks are functional, much as we might collectively wish you well in that regard.

---

From: Doug Barton <[email-masked]>
Date: Fri, 15 Jul 2011 15:39:59 -0700

John,

I think Brian and Joel both made excellent points about why this
suggestion is probably sub-optimal, and I won't presume to add to the
elegance of their arguments on those points other than to say that I
agree with them.

To address your concern about whether or not vendors are paying
attention to this discussion, and why historic status is substantively
different than "off by default, no really, OFF BY DEFAULT," I'll put my
FreeBSD developer hat on for a minute and tell you that we definitely do
pay attention to stuff like this, and whereas we already have it off by
default (and have for some time) moving it to historic gives us the
cover we need to remove the code at some point down the road when that's
appropriate. That's an extremely important distinction, and one of the
reasons that as a "member" of v6ops I ultimately came down in support of
the 2-document strategy.

hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Jul 2011 16:10:04 -0700

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Friday, July 15, 2011 12:43 PM
> To: Templin, Fred L
> Cc: [email-masked] Operations; IETF Discussion
> Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 
> transition issues)
> 
> You realize that you have not contradicted what Joel said, 
> right?     The IETF's business isn't making sure that 
> Boeing's networks are functional, much as we might 
> collectively wish you well in that regard.

If the IETF wishes organizations such as ours well, then
they should be willing to provide operational guidance.
RFCs 4057 and 4852 were a small step in that direction,
while 'draft-templin-v6ops-isops' provides actionable
information.

Fred

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Jul 2011 13:28:46 -0700

Joel's widget number 2

> usable within my organization's network.

Stasis is great if you can get it... There are two drafts proposing the use of shared address space space to be assigned by ARIN for LSN  that will probably turn up in opsawg.

Whether the get it or not the LSNs will be deployed.

And yeah I think Boeing probably has enough v4 addresses for a while.

Joel

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 16 Jul 2011 16:03:55 -0400

Hi John,

I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 2026's very terse definition of HISTORIC. According to RFC 2026, "A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level." That's the entire definition. Anything more is read into it.

Granted, the phrase "for any other reason considered to be obsolete" is pretty subjective. In this thread, I have seen people interpret that phrase as follows:

"the IETF thinks that there are no longer any valid use cases for this technology"
"the IETF recommends that you remove this technology from your network"
"the IETF believes that nobody is using this technology"

I doubt if any of these interpretations are valid, because the IETF is not in a good position to evaluate what is in use or tell an operator how to run a network. A more likely interpretation is as follows:

"the IETF is not likely to invest effort in the technology in the future"
"the IETF does not encourage (or discourage) new deployments of this technology.

                                                   Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joel Jaeggli
> Sent: Friday, July 15, 2011 3:17 PM
> To: John C Klensin
> Cc: [email-masked]; IETF Discussion
> Subject: Re: Another look at 6to4 (and other IPv6 transition issues)
> 
> 
> You missed the boat about a decade back I guess. Transition
> technologies (none of them) are a substitute for actual deployment.
> They should naturally decline in popularity and in fact in the portions
> of the internet where we can measure them they are. Right now if we try
> and fit a story to the evidence that is happening because of host
> changes, and  not because of deployment. ipv4 is becoming less usable
> and it's taking autotunnels with it, nobody here has a proposal that
> changes that.
>

---

From: Keith Moore <[email-masked]>
Date: Sat, 16 Jul 2011 16:49:35 -0400

> "the IETF is not likely to invest effort in the technology in the future"

Such a determination seems premature.  There are some ideas floating around for protocol fixes to deal with some of the operational problems associated with 6to4.  It's too early to know whether there are significant flaws with them or whether they can get traction.  Admittedly, v4 address space exhaustion along with the introduction of LSN means that 6to4 has diminishing applicability.  But for those nets and hosts that still have access to the public IPv4 internet, it's conceivable that the reliability of 6to4 can be considerably improved.  (Though of course it will never be as good as be as a well-run native v6 service.)   At some point, some evaluation of cost vs. benefit needs to be made; and the "cost" of not fixing 6to4 needs to consider the consequences of using other tunneled transition mechanisms besides 6to4.   

Put another way:  Given that there are admittedly several operational issues associated with 6to4, there are at least four strategies that might be employed:

1. Encourage changes to the operational practices that are causing problems that are associated with 6to4.
2. Discourage all use of 6to4 in the strongest possible terms.
3. Discourage use of 6to4 except in the cases where it is believed it can work well.
4. Improve the 6to4 protocol to address some of the issues.

IMO, -advisory tries to do #1;  -historic tries to do #2; -experimental tries to do #3.  #4 is something I hope can be discussed, informally, in Quebec.  We should have a better idea after the meeting how workable this is.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sat, 16 Jul 2011 18:52:38 -0400

--On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica
<[email-masked]> wrote:

> Hi John,
> 
> I think that most of the rancor around RFCs 3056 and 3068 is
> due to RFC 2026's very terse definition of HISTORIC. According
> to RFC 2026, "A specification that has been superseded by a
> more recent specification or is for any other reason
> considered to be obsolete is assigned to the Historic level."
> That's the entire definition. Anything more is read into it.

If you include a certain amount of oral tradition that predates
and surrounds 2026 in "read into it", I agree.  It may be worth
remembering that 2026, like most similar documents, didn't
invent anything but was intended to reflect a community
consensus that existed about what should be done.  Documents
like 2026 never capture that consensus exactly or
comprehensively.  Whether that informal consensus means anything
once we write something down is a question that we rarely ask
ourselves, probably for good reason.

> Granted, the phrase "for any other reason considered to be
> obsolete" is pretty subjective. In this thread, I have seen
> people interpret that phrase as follows:
> 
> "the IETF thinks that there are no longer any valid use cases
> for this technology" "the IETF recommends that you remove this
> technology from your network" "the IETF believes that nobody
> is using this technology"
 
> I doubt if any of these interpretations are valid, because the
> IETF is not in a good position to evaluate what is in use or
> tell an operator how to run a network. 

I think the first interpretation can be valid although it must
be used with great caution.   For example, I think we might all
agree that there are no remaining valid use cases for NCP,
despite the fact that TCP/IP could be argued to have replaced it
rather than precisely superceding it.  Another, perhaps better,
example is that Novell IPX is almost certainly dead
("proprietary protocol abandoned by its owner" is a pretty good
predictor of "no valid use cases").  We wouldn't think using it
for anything in a contemporary network would be useful even if,
e.g., it has better scaling properties.  Interestingly, while
RFC 1234 and 1553 were were moved to Historic, we have one Full
Standard (RFC 1123, STD 49), an Informational document (RFC
1634), a Proposed Standard (RFC 1420), and a some Experimental
documents (RFC 1791, RFC 1792).  That pretty much covers the
whole range of possibilities.    

If I didn't have the view that housekeeping exercises that
require community review and consensus were usually a poor use
of resources (see other note today), getting this whole pack
swept into Historic on the "no valid remaining use cases"
principle would be entirely appropriate.  One could still not
prove that no one is using it: I have every reason to believe
that someone out there is still running Netware and happy about
it.

> A more likely interpretation is as follows:
 
> "the IETF is not likely to invest effort in the technology in
> the future" "the IETF does not encourage (or discourage) new
> deployments of this technology.

Noting in passing that these sorts of statements are quite close
to the uses 2026 prescribes for Applicability Statements (and
for which we have even more precedent and oral tradition), if
the first of those is an adequate reason for identifying
something as historic, I recommend that we immediately move RFC
791 to Historic.  Certainly we are likely to invest more effort
in the development of the technology.  Now, some people would
read such a move as either an indication, as you suggest above,
that the IETF thought no one was using it any more, or that
there were no remaining valid use cases, etc., immediately
turning us into a laughingstock.  But, by logic that suggests
moving 6to4 to Historic on the grounds that the IETF is not
going to invest effort in the technology.

So I think we disagree.

best,
   john

>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Joel Jaeggli
>> > I understand the rationale.  At the risk of repeating
>> > myself, I simply do not think it works or is appropriate.
>> 
>> > set of documents as "Historic" is an extremely blunt
>> > instrument. If we do it in a consistent and logical
>> > fashion, the advice document would have to go to Historic
>> > along with the base documents because giving advice about a
>> > piece of ancient history is meaningless.  That is not what
>> > most people who like the advice document intended, at least
>> > as I understood the consensus on that Last Call.
>> 
>> <SNIP>
>> 
>> > Finally, if we had a wonderful transition model that would
>> > work well in all situations, then it would make sense to
>> > recommend it and depreciate everything else.
>> 
>> technologies (none of them) are a substitute for actual
>> deployment. They should naturally decline in popularity and
>> in fact in the portions of the internet where we can measure
>> them they are. Right now if we try and fit a story to the
>> evidence that is happening because of host changes, and  not
>> because of deployment. ipv4 is becoming less usable and it's
>> > some much better adapted to particular situations than
>> > others. It would be easier if we had a good single
>> > solution, but we don't... that is life, or at least
>> > engineering.  Given that, we serve the community much
>> > better with analyses and explanations of tradeoffs (and RFC
>> > 6180 is, IMO, a really good start) than we do by going
>> > through exercises of figuring out what to denounce. IMO,
>> > the _only_ thing we should be categorically denouncing are
>> > tactics and strategies that encourage people to put off
>> > getting serious about IPv6.  Unfortunately, trying to slap
>> > a "Historic" label on one particular transition strategy,
>> > or to rank transition strategies that have proven useful to
>> > some actors on the basis of how much various of us loathe
>> > them, are about denunciation and, however unintentionally,
>> > with the risk of encouraging people to sit and wait, not
>> > about progress or network engineering.
>> > 
>> > back to lurking...
>> >    john
>> > 
>> > 
>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 16 Jul 2011 20:27:39 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Friday, July 15, 2011 2:02 PM
> To: Brian E Carpenter

Well, if this is the prevailing opinion, we can certainly simplify our procedures substantially by eliminating about half of the document states we maintain now, including reducing the standards track down to a single state.

---

From: Doug Barton <[email-masked]>
Date: Sat, 16 Jul 2011 21:59:14 -0700

On 07/16/2011 07:02, John C Klensin wrote:
> 
> 
> --On Friday, July 15, 2011 15:39 -0700 Doug Barton
> <[email-masked]> wrote:
> 
>> attention to this discussion, and why historic status is
>> substantively different than "off by default, no really, OFF
>> BY DEFAULT," I'll put my FreeBSD developer hat on for a minute
>> and tell you that we definitely do pay attention to stuff like
>> this, and whereas we already have it off by default (and have
>> for some time) moving it to historic gives us the cover we
>> need to remove the code at some point down the road when that's
>> appropriate. That's an extremely important distinction, and
>> one of the reasons that as a "member" of v6ops I ultimately
>> came down in support of the 2-document strategy.
> 
> Doug,
> 
> And that is exactly where we agree on the effect and disagree
> about whether it is desirable.

Right.

> I think there is consensus that 6to4 is dangerous unless
> carefully and intelligently configured and that is certainly
> should not be turned on by default.  If anyone has argued
> against that position, they are in a tiny minority.  
> 
> Similarly, I think there is consensus that following the advice
> in the "advice" document makes 6to4 much safer to use, even if
> not entirely risk-free (I contend that there is no "risk-free",
> perhaps as a corollary to the principle that, if we invent
> something idiot-proof, someone will invent a better idiot).  So
> there should be no question about the desirability about
> publishing the content of that document.  

Agreed so far, especially about the idiots. :)

> The question, as far as the "advice" document is concerned, is
> how to get the message out most effectively, most clearly, and
> on as timely a basis as possible.  I think that having it
> "update" the base 6to4 specs is important because that is how
> the RFC Series is threaded.  Without that, there is an increased
> risk of people finding the 6to4 specs and implementing them
> without ever seeing the "advice" piece (just as, even with the
> "updates"/"updated by" pointers, we still hear about new TCP
> implementations based on RFC 793 alone).  For the reasons
> discussed above, I don't think anyone would find that outcome
> desirable. 

You know the subtleties of the various document tracks infinitely better
than I do, so I'm not even going to try and debate you on that.

OTOH, I find the idea of someone implementing 6to4 from scratch at this
point highly unlikely. I also think that declaring it historic would
make the scenario you describe that much more unlikely.

[snip]

> But, while some people have argued that 6to4 has caused so much
> damage by being misconfigured that it should, presumably as
> punishment or to create a public example, be eliminated entirely
> as an option

My perspective, which I've described at length many times now, is not
that 6to4 needs to be punished, but that the widespread deployment of
IPv6 is being harmed as a result of the negative user experience that it
creates for the majority of its users (particularly the unintentional
ones) and therefore the network as a whole is better off if it goes away.

To summarize my main points once again (since you seem determined to
reopen the debate on 6to4's utility):

1. There is next to zero IPv6-only content at this time.
2. Therefore the number of people who actually *need* IPv6 is so close
to zero as to not be a factor.
3. Of the tiny number of people that actually do need IPv6, there are
plenty of other tunnel options.
4. By the time that there *is* IPv6-only content the market will have
sorted out access for the average user.

Thus, 6to4 hurts way more than it helps at this point.

Furthermore you have the huge problem that neither end of the 6to4
equation has *any* motivation to fix it. The ISP side can simply block
tunnels (or even simpler, ignore the problem). The content side can
simply not deploy AAAA records.

I do think that the -advice document is a good thing, and for those that
care I think it's great that the IETF is going to help them out. But all
statements of the form "all we need to do to fix 6to4 is X" are
non-starters because the people with the ability to actually fix it are
not going to.

> -- for FreeBSD users, the exact effect of your removing the code --

To be clear, I didn't say that we *will* remove it, only that making it
historic gives us that opportunity at some point down the road *if* that
becomes appropriate.

> I haven't seen nearly as strong as case, or
> anything even close to consensus, for that position.   If it was
> actually what the community believed, then the "advice" document
> would be a complete waste of time except possibly as a
> retrospective on how 6to4 might have been better specified (a
> retrospective that we would want to publish as (immediately)
> Historic).

Once again repeating myself, but I disagree. The idea of publishing both
documents represents a fine compromise between the 2 extreme positions,
and allows those who want to continue using it to do so in the best way
possible. It's also not the first time the IETF has published a document
that says, effectively, "We don't think you should do this, but if
you're going to do it anyway, here's how to do it right."

> If the thing is still useful, even in limited circumstances and
> used correctly, then the IETF should not provide you with
> "cover" to remove the code because it is not in the best
> interest of the community for you to remove the code.   Might
> both your removing the code and moving 6to4 to Historic in the
> future be appropriate?  Sure.  I also look forward to the day
> when we can move IPv4 to Historic (just as the various
> specifications that make up NCP should have been moved years ago
> if we paid attention to that sort of housekeeping).

So the debate is on the timing. I (and others) think that the time is
now. My opinion is that there is also a pretty strong community
consensus that the time is now, modulo a very vocal group of people who
do not. But fortunately I'm not the one who has to make the decision
about what there is and is not consensus for. :)

[snip]

> FWIW, I note that there are at least a few other things that
> shipped for years with FreeBSD that could cause a lot of damage
> if misconfigured and were hard to configure correctly, but were
> nonetheless included in the code in version after version and
> even were enabled by default.  Getting rid of them would not
> have required any IETF action -- there were other
> implementations of the same protocols that could have been
> included in the base systems instead.  But they weren't removed
> or replaced (the folks who produced them eventually produced
> better versions). 

Putting my FreeBSD hat back on for a second, we're always interested in
improving our code base, and would certainly not want to intentionally
do anything to "cause a lot of damage." If there are concrete concerns
anyone should feel free to file a Problem Report at
http://www.freebsd.org/send-pr.html, or use the 'send-pr' utility in
FreeBSD.

> But I don't recall seeing the sort of venom
> that is directed toward 6to4 being focused on them.  Perhaps
> there weren't enough complaints or you have solid data that 6to4
> has caused even more damage.

Once again repeating myself ... I have no venom towards 6to4. This isn't
a personal attack. And yes, various people and organizations that have
vested interests in seeing IPv6 deployed have posted the data about why
6to4 causes way more problems than it solves, and I believe them.

Doug

--

---

From: Keith Moore <[email-masked]>
Date: Sun, 17 Jul 2011 11:17:37 -0400

> ones) and therefore the network as a whole is better off if it goes away.

It doesn't follow.

Nor would declaring 6to4 Historic (or any other label) have that effect.   It could easily make things worse for both users and content providers, by giving people the mistaken impression that "remedial" actions like filtering protocol 41 or advertisements for 6to4 relay routers are good ideas.   

The fixes for unintentional users of 6to4 are already in the pipeline.  Everybody agrees that the default address selection preferences should be changed to prefer native IPv4 over 6to4, and host platforms (including FreeBSD I assume) have already changed these preferences or are in the process of doing so.    Most platforms have ways of pushing urgent updates to their users, and IMO this change in the address selection preference list should qualify for such updates.   (As for the users who don't make use of that feature and/or turn automatic updating off, declaring 6to4 Historic would not make them more likely to use such updates.)

> to zero as to not be a factor.

#2 does not follow from #1, for various reasons.   One reason is that the Internet is highly diverse, and people use it for many other things than to download "content" from "content providers".

> plenty of other tunnel options.

...which are often worse than 6to4, for some meaning of "worse" (more overhead, longer delay, greater likelihood of path congestion, single point of failure, reduced probability of getting a connection established).

> sorted out access for the average user.

The market hasn't sorted out IPv6 access in the past 15+ years, mostly because of the lack of any new v6-only applications or usage scenarios that would drive IPv6 deployment.   Under current conditions, there is zero incentive to produce IPv6-only content because would block 99.99% of the potential market for said content.   HTTP and SMTP will be the last protocols to migrate to IPv6, not the first ones.   Prior to widespread deployment of IPv6 access, any use of HTTP-over-IPv6 to serve content to the public, or SMTP-over-IPv6 to exchange mail between arbitrary administrative mail domains, is either a proof-of-concept or a publicity stunt.  

So the idea of waiting until there is IPv6-only content to drive the market to provide IPv6 access for the average user, is a nonstarter.

> Thus, 6to4 hurts way more than it helps at this point.

It doesn't follow even if one accepts the premise of #4 (which is not a reasonable premise).

And again, nobody disputes that unintentional use of 6to4 is harmful.  But that fix is already in the pipeline, via much more effective means than any label that could be put on 6to4.

> simply not deploy AAAA records.

Blocking tunnels makes the situation worse both for users (who will experience even more connection failures) and for operators (who will experience even more support calls).   We need to get that message out as loudly and as clearly as possible.

As for content providers, there are lots of ways for them to provide content over HTTP-over-IPv6 without exposing that content to 6to4 users, or (better) without exposing that content to users with poor IPv6 connections.   

One way is this: make the initial connection - the advertised URL - use a domain name which only has A records.  This is safe to do because for the foreseeable future, everybody will have some kind of IPv4 HTTP access.   Have the initial connection provide referrals to the "real" content using one of two different domain names, based on whether the source address is within 2002::/16: ipv4.example.com only returns A records, ipv6.example.com returns both AAAA and A records.  A lot of content is using referrals for various reasons anyway, so it might be possible to do this without any additional overhead.  Offhand this seems a lot more reliable than playing games with DNS.

Another, perhaps better, way:   Again, have the advertised URL use a domain name that only has A records.   Have the main page set a cookie, the value of which is based on a timestamp.   Also have the initial page load a one-pixel image via a URL with a domain that only has IPv6 addresses.  This image sets its own cookie, also based on a timestamp.   If the server gets a request with the v4 cookie's timestamp much earlier than the v6 cookie's timestamp, or if the v6 cookie is missing, make all links and referrals use only A records.  If the v4 and v6 cookies are both present and have similar timestamps, the links and referrals can have AAAA records.

Of course both of the above depend on using different URL domains depending on whether the content provider wants to provide v4-only or dual-stack service to the client.  The content provider might prefer to use the same domain in both cases and play games with DNS based on the requester address.  (which causes a different set of issues).  

But at least with the web, it seems like enough tools are there to let content providers serve content via v6 when it works well, and minimize use of v6 for those users for whom it doesn't work well, as well as to keep track of how often v6 is working for their users.  Admittedly, it's a bit more work than just adding AAAA records to existing DNS names and enabling v6 on the servers.    

> non-starters because the people with the ability to actually fix it are

Speculation.    

How can we expect people to have "fixed" 6to4 without their being clear recommendations for how to do that?   Arguably, a lot of the problems that we're seeing with 6to4 are the results of poorly chosen "fixes" (like protocol 41 filtering) that actually exacerbate the problem.

(For that matter, how do you know that people aren't slowly discovering how to "fix" 6to4, and doing it?   I assure you, 6to4 works better now than it did 10 years ago.  It's reasonable to believe that the measures in -advisory will also help the situation.)

> historic gives us that opportunity at some point down the road *if* that

The FreeBSD developers can do whatever they like with their code.   They don't need for IETF to declare it anything.  If they want to remove 6to4 support, they can do so and deal with the criticism and/or praise from their users.   

Hopefully, "at some point down the road", presumably when native IPv6 is widely available, it will make sense to declare 6to4 Historic, and we'll all celebrate when that happens.  

> about what there is and is not consensus for. :)

From my perspective, the "very vocal group of people" is in v6ops, which is heavily biased toward the operator's viewpoint, and against the user's and application developer's viewpoint.  They haven't even tried to get community consensus on this.

> 6to4 causes way more problems than it solves, and I believe them.

They've posted data about why unintentional use of 6to4 causes more problems than it solves.  And that's being fixed.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sun, 17 Jul 2011 16:32:32 -0400

--On Saturday, July 16, 2011 20:27 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>> Behalf Of John C Klensin Sent: Friday, July 15, 2011 2:02 PM
>> To: Brian E Carpenter
>> difference in this space because people will follow advice
>> that seems sensible and ignore everything else.  If so, it
>> makes little difference how your document is approved or
>> where it is published.  For example, it could have come
>> through the Independent Stream or been pushed into CCR.  No
>> problem.  And the "Historic" effort is a huge waste of the
>> community's time, no matter how it comes out.
> 
> Well, if this is the prevailing opinion, we can certainly
> simplify our procedures substantially by eliminating about
> half of the document states we maintain now, including
> reducing the standards track down to a single state.

I certainly would not claim it is the prevailing opinion.  I
believe it is true and have seen it in action many times but,
beyond that, have no idea.   Also remember that the Standards
Track (including BCP or not), Experimmental, Informational,
Historic breakdown is somewhat orthogonal to the maturity levels
within Standards Track.

That said, I believe, based in part on consensus in at least one
WG that focused on the topic, that, as our standards have become
more complex, with more features, options, and interactions, the
embodiment of the "maturity level" idea as a single set of
category-identifiers has outlived its usefulness.  The reality
is that some features of a particular specification may be
well-tested and very mature while others may still be a bit
questionable and that some specifications may be more
appropriate to some environments and less appropriate to others.
>From that point of view, forcing entire protocols or
specifications into one category or another does both the IETF
community and the users of the specs a disservice: we should be
telling people what we think of a spec, how mature things are,
and what the issues are, if necessary on a
characteristic-by-characteristic basis, not pretending that
assignment of a label communicates significant information.
>From that point of view, reducing the number of categories
increases the odds of classifications being misleading and
communicating little real information, if only from "very
likely" to "near-certain".  But, again, that is just IMO.

    john

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 18 Jul 2011 09:36:02 +0200

>> <[email-masked]> wrote:
<snip>
> ones) and therefore the network as a whole is better off if it goes away.

That do sum it up pretty good.

<snip>
> simply not deploy AAAA records.

My wild guess is that the ISP will sooner or later stop routing the entire
2002::/16 block...  and _yes_ that will hurt bad but it will force a hard error
on the whole 6to4 issue. It's so much better with one hard error than lots
of possible errors.

<snip>
> 6to4 causes way more problems than it solves, and I believe them.

I dare to say the content providers want 6to4 gone because it _can_ be
pointed at as a risk when enabling IPv6.
And I do think the ISP see this as a quite black/white problem _if_ they
have to deal with it. Either 6to4 are on and working all the time without
them doing much, or it's gone.

And this will be my last post on the subject at all, see no point in using more
time on it. Lets move on :)

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sat, 16 Jul 2011 10:02:10 -0400

Doug,

The question, as far as the "advice" document is concerned, is
how to get the message out most effectively, most clearly, and
on as timely a basis as possible.  I think that having it
"update" the base 6to4 specs is important because that is how
the RFC Series is threaded.  Without that, there is an increased
risk of people finding the 6to4 specs and implementing them
without ever seeing the "advice" piece (just as, even with the
"updates"/"updated by" pointers, we still hear about new TCP
implementations based on RFC 793 alone).  For the reasons
discussed above, I don't think anyone would find that outcome
desirable.  As to whether there should be a single document or a
separate Applicability Statement that points to both the base
specifications and the "advice" document, I'm really pretty
agnostic even though I don't see many advantages in two
documents.   A separate Applicability Statement that does update
the base documents but points to the "advice" one would
accomplish much the same purpose and eliminate the requirement
that the "advice" document explicitly update the base ones.
While I think publishing a separate document just to avoid that
linkage would waste time, I'm actually pretty agnostic about
that option too.

as an option -- for FreeBSD users, the exact effect of your
removing the code -- I haven't seen nearly as strong as case, or

Summary: we should not move something to Historic that is still
in use, useful, and that can be used correctly.  We explain how
to use it or the circumstances under which is should or should
not be used, narrowing those descriptions as much as needed.
And/or we explain all of the situations in which it should not
be used.  Simply reclassifying it as Historic is problematic to
the use cases that actually do work and doesn't provide nearly
enough information as what people should actually do, especially
people who already have the protocol deployed in some form.
Using Historic, rather than, e.g., NOT RECOMMENDED [any more] as
a sort of super-deprecation mechanism depends too much on our
assumption that people with working deployments will simply
ignore us.  While the assumption is right, it puts the whole
situation into one in which the IETF is publicly operating on
the assumption that its advice won't be followed.   If we do
that very often, we might as well just go home.

better versions).  But I don't recall seeing the sort of venom

   best,
     john

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Jul 2011 10:32:28 -0400

> on the whole 6to4 issue. It's so much better with one hard error than lots

Actually, no.  It will cause a significant increase in the number of service calls that will last for years.  And those will be the fault of the ISPs blocking the traffic.

It must be re-iterated that the vast majority of problems associated with 6to4 appear to be caused by operators, not by 6to4 itself.  6to4 does have some real problems, and some of us are looking for ways to fix them.   But that's no excuse for operators to deliberately make things worse.

> them doing much, or it's gone.

Part of the problem seems to be that operators want a quick solution that is under their control, when it appears that no such solution can exist.

- Changes to the default address selection rules, already implemented or being implemented, should help significantly, but it will take some time for hosts to get updated to reflect those changes.  (Asking Microsoft, Apple, and Linux vendors to include those changes in incremental updates - if they haven't already done so - might help speed that process along.)
- The changes in -advisory will help somewhat, but it will take time for operators and vendors to learn about them and implement them, and the effect will be gradual.
- The changes in -experimental will also help somewhat, if those changes are published in some form, but the effect will also be gradual.
- Improvements to the 6to4 protocol (especially where relay routers are concerned) might help, but again will require updates to hosts and/or routers.   (it's conceivable that fixes could be implemented in hosts that don't require the routers to be upgrade in order for those changes to be helpful)
- As I said yesterday, there are ways that content providers can use IPv6 to distribute content to their customers over HTTP, as well as monitor the percentage of their users that are IPv6 capable, though they're a tad trickier than simply adding AAAA records to the DNS and turning on v6 in their servers.

All of the above can help.   However,

- Yelling "6to4 is Evil" as loudly as possible, e.g. declaring it Historic and publishing -historic,
- Filtering protocol 41 packets,
- Blocking 2002::/16 traffic or routing advertisements, or
- Blocking 192.88.99.0/24 traffic or routing advertisements, 

will all make the situation worse for users, operators, and content providers. 

Keith

---

From: james woodyatt <[email-masked]>
Date: Mon, 18 Jul 2011 12:30:00 -0700

On Jul 18, 2011, at 24:36 , Roger Jørgensen wrote:
> 
> My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block...

You mean, your wild guess is service providers will unilaterally implement the phase-out plan I proposed as a standards action.

Why not just sign up for a standard phase-out plan?  Don't we want 6to4 users to have any advanced notice that we plan to break their Internet?  Or, is the idea that we don't believe we can achieve a tactical victory over 6to4 users unless we mount a surprise attack on them?

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Jul 2011 15:57:17 -0400

> Why not just sign up for a standard phase-out plan?  Don't we want 6to4 users to have any advanced notice that we plan to break their Internet?  Or, is the idea that we don't believe we can achieve…

I don't understand the desire for a phase out plan when there's nothing better to phase in that's generally available.    

Preferring IPv4 to 6to4 makes sense.     But filtering 6to4 traffic or its routing advertisements is a denial-of-service attack.

Keith

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 20 Jul 2011 00:01:42 +0300

> going to invest effort in the technology.

Quite so.  And with that, you've just ruined the best April 1 gag the IETF could have hoped for, you. :-)

I stopped to consider, and do again, what exactly would prevent us from taking such a radical course of action.  Clearly, the view that making something historic when it's in active use is offensive.  No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position.  On the other hand, as you've shown, case-by-case analysis is a good thing for document action on historic (or any other status), and there are a body of cases where the merits of documents have not shown to be sufficient for the IETF to consider it worthwhile improving.  I wasn't about in the early days of the IETF so I don't know anything about these oral traditions you speak of, except to say that this is a case to be made for the force of the written word.

BTW, I am among those not exactly thrilled about the idea of moving of 6to4 to historic.

Cheers,
Sabahattin

---

From: Doug Barton <[email-masked]>
Date: Tue, 19 Jul 2011 14:34:32 -0700

On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
> Clearly, the view that making something historic when it's in active use is offensive.  No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position.

Define "active use."

--

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 19 Jul 2011 15:41:16 -0700

>> Clearly, the view that making something historic when it's in active use is offensive.  No standards body could seek to stand behind their specifications, or to give the impression of doing so, wi…

That's a fairly odd position to take, if we do something which turns out to be a bad idea, should we stand behind it regardless of the validity of the criticism?

The number of drafts, I've seen over the course of the last decade and a half with the title "foo considered harmful" woulkd tend to indicate otherwise. 

> Define "active use."

If in fact no-one were using it there would be little point in engaging in the activity.

rfc 5095 and 4966 were not created to address issues that were due to protocols being dead to the world...

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 20 Jul 2011 02:24:49 +0300

On 20 Jul 2011, at 00:34, Doug Barton wrote:
>> Clearly, the view that making something historic when it's in active use is offensive.  No standards body could seek to stand behind their specifications, or to give the impression of doing so, wi…

Actively being used.  In production.  So that taking it away would hurt the entity using it, threaten the entity's comfort and convenience, or just generally go against the stated goals of making the Internet a better place for everybody through the instrumentation and maintenance of standards.

But none of us like IPv4 and that's a fact.  Last one to sign the action to move it to historic's a yellow-belly.

Cheers,
Sabahattin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Jul 2011 19:38:59 -0400

After all, we moved RIPv1 to Historic when it was still widely 
implemented, and used in many networks.
Yours,
Joel

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 20 Jul 2011 03:19:23 +0300

On 20 Jul 2011, at 01:41, Joel Jaeggli wrote:
> That's a fairly odd position to take, if we do something which turns out to be a bad idea, should we stand behind it regardless of the validity of the criticism?

No.  But if it's in active use, we have something of an obligation to the users.  The fact that it's in use is a fairly clear indication, regardless of technical quality (the review process being meant as an aid to identifying the more obvious problems before publication) that it is or can be made to be useful.  That's an argument in favour.  I don't dispute that protocols can turn out to be harmful, and there's a good vs bad benefit analysis to be made for lots of different reasons, but as has already been said before, the historic label is an *extremely* blunt instrument that is almost always reserved for specifications that have actually come to rest, following the logical English definition of "Historic" or "Historical".  Better for the community to be informed about the good and bad of protocols with troublesome aspects.

> If in fact no-one were using it there would be little point in engaging in the activity.

Right, precisely.  If the call weren't made, or it were made but happily ignored by everyone, I think we can take it as red that nobody minds too much.

> rfc 5095 and 4966 were not created to address issues that were due to protocols being dead to the world...

Well, FWIW, NAT-PT is still implemented and in use, most recently for evil purposes.  But once again, the designation means that the protocol has reached the end of its useful service life; there is no further use that can't be better served with our newer, shinier standards.  That is something we explicitly indicate, so implementers can get on and implement the better solution.  And in every case, we have "Applicability statements" or "Reasons to move" documents, so the community understands.

Cheers,
Sabahattin

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jul 2011 07:47:01 -0400

yes, but if I'm not mistaken, you already had RIPv2 then.

Keith

On Jul 19, 2011, at 7:38 PM, Joel M. Halpern wrote:

> After all, we moved RIPv1 to Historic when it was still widely implemented, and used in many networks.
> Yours,
> Joel
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Jul 2011 11:40:23 +0200

> Actively being used.  In production.  So that taking it away would hurt the entity using it, threaten the entity's comfort and convenience, or just generally go against the stated goals of making t…
The idea that moving a standard to Historic would take away the ability 
of people to use it reminds me of the story from the Norwegian army, 
approx 1939:

- "If the enemy invades, how will you prevent them from using the train 
network?"
- "Burn all the tickets, sir!"

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Jul 2011 13:00:02 -0400

--On Thursday, July 21, 2011 11:40 +0200 Harald Alvestrand
<[email-masked]> wrote:

>...
>> Actively being used.  In production.  So that taking it away
>> would hurt the entity using it, threaten the entity's comfort
>> and convenience, or just generally go against the stated
>> goals of making the Internet a better place for everybody
>> through the instrumentation and maintenance of standards.
> The idea that moving a standard to Historic would take away
> the ability of people to use it reminds me of the story from
> the Norwegian army, approx 1939:
> 
> - "If the enemy invades, how will you prevent them from using
> the train network?"

I like this analogy.  The proposed action would have no effect
whatsoever on the behavior that one is trying to discourage.
But the move makes the party recommending the action look
ridiculous, ridiculous enough that the story of the
recommendation is still being told move than 70 years later.

     john

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jul 2011 09:09:52 +1000

> recommendation is still being told move than 70 years later.

Except there are vendors who have already threatened to remove the
6to4 code if it is declared historic then you are left between a
rock and a hard place if you need to upgrade the software on the
6to4 router for other reasons and still want to use 6to4.

Not everyone is in the position to just board the train they want
by force to take the analogy a little further.

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