Subject: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 17 Apr 2011 11:00:05 -0700

This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-advisory. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Apr 2011 08:37:19 +0900

this proposal is far too mild.  6to4 should not be less preferred, it
should be removed.  it is damaging to ipv6 in that it gives the users
the belief that ipv6 sucks, when it is 6to4 that sucks.

randy

---

From: Tore Anderson <[email-masked]>
Date: Mon, 18 Apr 2011 09:18:42 +0200

* Fred Baker

> This is to initiate a two week working group last call of
> draft-ietf-v6ops-6to4-advisory. Please read it now. If you find nits
> (spelling errors, minor suggested wording changes, etc), comment to
> the authors; if you find greater issues, such as disagreeing with a
> statement or finding additional issues that need to be addressed,
> please post your comments to the list.
> 
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.

I support this document. While the preferred long-term solution is to
avoid unsolicited use of 6to4 entirely (i.e. 6to4-to-historic); in the
short term, it can only help to try to alleviate the pain that is being
caused by problematic implementations that have already found their way
into people's homes.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27

---

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

On Sun, Apr 17, 2011 at 8:00 PM, Fred Baker <[email-masked]> wrote:
> (spelling errors, minor suggested wording changes, etc), comment to the
> authors; if you find greater issues, such as disagreeing with a statement or
> finding additional issues that need to be addressed, please post your
> comments to the list.
> We are looking specifically for comments on the importance of the document
> as well as its content. If you have read the document and believe it to be
> of operational utility, that is also an important comment to make.

I support this document, it is one step in a long process of making
IPv6 more robust and stable for everyone.

-- 

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

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 18 Apr 2011 11:22:34 +0200

> IPv6 more robust and stable for everyone.

+1.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 18 Apr 2011 12:59:50 +0200

+1
One can only promote improving the existing situation.

Nevertheless the 6to4 should be made historical to control the increasing the 
negative influences of 6to4 on the ever growing internet.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Roesen
Sent: 18 April 2011 11:23
To: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC

+1.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: [email-masked]
Date: Mon, 18 Apr 2011 13:27:31 +0200 (CEST)

> caused by problematic implementations that have already found their way

Support from an operator here.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Mon, 18 Apr 2011 12:50:00 +0000

Support. This document is critical to ensuring that 6to4 works as well as possible while there are still a non-trivial number of
deployments in the wild.

Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Sunday, April 17, 2011 2:00 PM
To: [email-masked]
Cc: [email-masked]; Ron Bonica
Subject: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC

This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-advisory. Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing
with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important comment to make.

---

From: <[email-masked]>
Date: Mon, 18 Apr 2011 13:08:55 +0000

Support as well.

Somebody should make sure that there is no side-effects on RFC5969 (6rd) that references RFC3056 several times.

Guillaume (Operator)

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gunter Van de Velde (gvandeve)
> Sent: Monday, April 18, 2011 1:00 PM
> To: Daniel Roesen; [email-masked]; [email-masked]

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Mon, 18 Apr 2011 09:10:21 -0400 (EDT)

Support.

wfms

---

From: Martin Millnert <[email-masked]>
Date: Mon, 18 Apr 2011 10:15:13 -0400

v6ops,

> > IPv6 more robust and stable for everyone.

*2

Best,
Martin

---

From: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Date: Mon, 18 Apr 2011 10:29:56 -0400

+1

Barbara

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 18 Apr 2011 10:00:55 -0500

> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an importa…

I support this document, but considering nearly all of our site's failures 
with 6to4 (and IPv6, for that matter) is section 4.1.5, I see two issues:

- This is hardly discussed in section 3

- The text 4.1.5 may not be strong enough to disable this awful behavior.  
I would claim that an "internet sharing" host MUST not ever advertise 6to4 
prefixes.  This would very much help the interim situation between now
and when 6to4 is off by default.  I am not sure that setting the
preference to low actually would change anything.

Dale

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 Apr 2011 20:52:56 +0200

> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an importa…

I support this document.

two comments:
  [I-D.vandevelde-v6ops-harmful-tunnels]. as I'm not entirely certain if we will continue this document now that we have the two 6to4 document, you may want to remove this reference.

section 4.1. on vendor issues. I would have liked to see a suggestion of a "reachability check" for the 6to4 relay. and make that as a prerequisite to enable the 6to4 function in an implementation. a reachability check could be as simple as sending an ICMP echo packet to one of ones own addresses via the 6to4 relay.

cheers,
Ole

---

From: Michael Newbery <[email-masked]>
Date: Tue, 19 Apr 2011 13:50:14 +1200

> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an importa…

Support, from an operator. Anything that helps in the short term is to be applauded, while I continue to beat on my vendors to fix their equipment so I can deploy the real thing.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Apr 2011 14:22:31 +1200

> Somebody should make sure that there is no side-effects on RFC5969 (6rd) that references RFC3056 several times.

I don't think so. The recommendations that are most likely to
affect 6rd are ones like 'don't filter Proto 41', 'don't block
PMTUD' and 'don't run 6to4 relays unintentionally' that can only
help 6rd run better.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Apr 2011 14:38:03 +1200

> the belief that ipv6 sucks, when it is 6to4 that sucks.

I'm not sure this comment was really addressed to the document
in question, whose goal is to reduce the sucking; it's the other
document that attempts to reinsert the toothpaste into the tube.

> - This is hardly discussed in section 3

True. I only realised the seriousness of this issue for some
sites very recently; I can expand the text.

> preference to low actually would change anything.

If there is no other source of RAs it clearly won't help. I can
strengthen the language, but this draft is not standards track,
so you will have to campaign elsewhere for an official MUST NOT.

>   [I-D.vandevelde-v6ops-harmful-tunnels]. as I'm not entirely certain if we will continue this document now that we have the two 6to4 document, you may want to remove this reference.

If you can make a definite statement like "we will not continue
this document" the choice will be easy ;-)

> section 4.1. on vendor issues. I would have liked to see a suggestion of a "reachability check" for the 6to4 relay. and make that as a prerequisite to enable the 6to4 function in an implementation.…

I think the idea is a good one (also see
draft-nward-6to4-qualification), but I don't think we should
recommend vapourware to ISPs in this draft, which is trying to
say what can be done this afternoon or tomorrow morning.

Thanks
    Brian

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Tue, 19 Apr 2011 03:58:13 +0100

Hi Brian,

Section 4.4

I would say that the assumption IXPs have IPv6 connectivity is false.

Modern Internet Exchange Points (IXP)  are recognized to be layer2
providers. They have v6 addressing on the IXP-LAN, but that address
space may or may not be routed (in most cases, it's not routed).

Recommending that IXP provide any kind of transit service (6to4 relay is
transit to 6to4 packets) is a major NO in my books.

Otherwise, I have read the draft and support it.

- -gaurab

On 4/17/11 7:00 PM, Fred Baker wrote:
> authors; if you find greater issues, such as disagreeing with a
> statement or finding additional issues that need to be addressed, please
> post your comments to the list.
> 

- -- 

http://www.gaurab.org.np/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Apr 2011 15:12:59 +1200

On 2011-04-19 14:58, Gaurab Raj Upadhaya wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Brian,
> 
> Section 4.4
> 

Well, clearly the recommendation can only apply to an L3 service
provider, so the draft should make it clear that it only refers to
IXPs that are providing L3 services in general. Let's not discuss
here whether that is a good or bad choice for an IXP.

   Brian

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk2s+kUACgkQSo7fU26F3X0OswCgyqCyfEOw/xAaIki+hEqTMFQx
> rcAAoKuobMqnL5c3G1ccgbrcG1oTawg8
> =dZku
> -----END PGP SIGNATURE-----

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Tue, 19 Apr 2011 05:26:34 +0100

>> here whether that is a good or bad choice for an IXP.

I disagree with the definition that an IXP can provide L3 transit
services of any kind. When it does, it becomes an transit provider and
ceases being an IXP.

FWIW, I know do not know of any IXP, that provide L3 services in
general. What can those be ? May be you can give some examples, if I am
missing something there.

- -gaurab

- --

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Apr 2011 14:50:36 +0900

> general. What can those be ? May be you can give some examples, if I
> am missing something there.

ntp, name servers, ...

randy

---

From: "John Mann (ITS)" <[email-masked]>
Date: Tue, 19 Apr 2011 16:00:35 +1000

Hi,

>From the " [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question"
thread,
 james woodyatt <[email-masked]> wrote on 14 April 2011 03:05
> When I review the data at <http://stats.ottix.net/ipv6/>, what I see is
that a lot of academic networks are numbering their local area networks with
public IPv4 addresses and that a fair > number of hosts on those networks
are successfully getting workable IPv6 service over 6to4 through the Ottowa
IX anycast relay. ...

More-generally, http://ottix.net/resources.html
they provide for their members and customers DNS, FTP, 6to4, NNTP, NTP,
router servers, Web, whois

Thanks,
    John

On 19 April 2011 14:26, Gaurab Raj Upadhaya <[email-masked]> wrote:

> iEYEARECAAYFAk2tDvoACgkQSo7fU26F3X12JQCdF9LGuiOGyzd15rsiLfy/Tjli
> VNIAn0SnyMcLbyTAbjUC//gg2VN4/yiX
> =fSj4

---

From: Frank Habicht <[email-masked]>
Date: Tue, 19 Apr 2011 09:59:08 +0300

Hi,

first time, so be gentle ;-)

>> am missing something there.

Randy:
s/provide L3 services/provide L3 transit services/

agree with Gaurab.
would like see "IXP" gone from that section.

under 2. inside that section:
"If it reaches a wider scope, the relay will be offering a free ride to
non-clients"

replaced by " .... non-transit-clients"  ?

though don't want to delay this ID.

haven't read all of the ID yet.
need to have the anycast 6to4 be disabled/unused [1] first before
removing prefixes and reverseDNS

Frank

[1] by OS vendors, and they are on the list.

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Apr 2011 17:20:06 +0900

> s/provide L3 services/provide L3 transit services/

i strongly agree that, if the IX provider offers transit, then they are
not an IX provider, they are a transit provider with a switch.

randy

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Tue, 19 Apr 2011 10:54:49 +0100

>> am missing something there.

To rephrase myself, these services are not same as providing transit.

With a 6to4 relay, the IXP essentially gets into a position where it's
passing packets through its relay to another network. So, it's then a
transit provider. The references to IXP in this document is not necessary.

- -gaurab

- --

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Apr 2011 09:36:28 +1200

> not an IX provider, they are a transit provider with a switch.

Fair enough. I will rephrase this accordingly.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Apr 2011 11:27:14 +0300 (EEST)

> believe it to be of operational utility, that is also an important comment to make.

I suppose publishing this document but not in its current form; 
some changes are needed (below).

....

Section 2.1 on Router 6to4 should be trimmed down, one page is 
excessive.  6to4 was never deployed as it was initially devised by 
Carpenter, so text on that is not very useful (most of 1st paragraph 
of Section 3 should also go away).  The key point is that 6to4 hosts 
or routers may either configure the relay router IP address or use 
anycast.

In S 3: "The inference from
    these experiments is that one likely reason for the high connection
    failure rate for 6to4 connections is the use of local filters close
    to the end-user that block incoming packets with protocol 41."

.. it was not described if the return path relay used 192.88.99.1 as 
the source address of packets or the non-anycast address.  I would 
expect significantly more breakage when 192.88.99.1 is NOT used as the 
source address.  Firewalls in residential case are rarely an issue 
based on my experience if the relay uses 192.88.99.1 as the source 
address.

    5.  PMTUD Failure: ...Path MTU Discovery does not
        always work, and this can lead to connectivity failures.  Even if
        a TCP SYN/ACK exchange works, TCP packets with full size payloads
        may simply be lost.

.. due to MSS negotiation this is not a problem if 6to4 is set up on a 
host because it will set MSS lower than 1500-40=1460B. This however 
could be a problem if 6to4 is enabled on a router and it advertises 
the prefix on a LAN, because if it doesn't also advertise a smaller 
MTU, hosts on the LAN will use MSS=1460 and TCP MSS negotiation will 
fail.

   The practical impact of the above problems, which are by no means
    universal as there is considerable successful use of Anycast 6to4,
    has been measured at a fraction of 1% loss of attempted connections
    to content servers (see <http://www.fud.no/ipv6/>).

.. for more balanced discussion, this discussion should be moved up, 
next to the two researches on "very broken 6to4".

Section 4.1 is out of place here.  Remove or broaden the scope of the 
document to include vendors.

S 4.2:
    Unless the answer to all these questions is 'yes', subscribers will
    be no worse off, and possibly better off, if the route to 192.88.99.1
    is blocked and generates an IPv4 'destination unreachable'.  There is
    little operational experience with this, however.

.. this must be removed unless there is more operational experience 
with this approach.  Hinting at the ISPs that this could be a good 
approach is very wrong if we don't know that it is actually the case.

editorial:

- references to labs.ripe.net, www.potaroo.net etc. should be filed as 
informative references not direct URLs in text.

- S 4.2 is almost two pages long.  It would be better focused with 
subsections.

- S 4.4: as already commented by others, remove IXP

- S 4.5: s/suceeds/succeeds/; s/firewallls/firewalls/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Apr 2011 11:14:47 +1200

Hi Pekka,

Thanks for the review.

On 2011-04-20 20:27, Pekka Savola wrote:
> I suppose publishing this document but not in its current form; some
> changes are needed (below).
> 
> ....
> 
> Carpenter, so text on that is not very useful (most of 1st paragraph of
> Section 3 should also go away).  The key point is that 6to4 hosts or
> routers may either configure the relay router IP address or use anycast.

You made this comment on an earlier version. I disagreed then and I disagree
now. It's impossible to understand how the anycast version is supposed to
work unless you understand how basic 6to4 is supposed to work, and the
situation for the return relay is the same in both cases. I couldn't find
anything redundant in the explanation.

> .. it was not described if the return path relay used 192.88.99.1 as the
> source address of packets or the non-anycast address.  I would expect
> significantly more breakage when 192.88.99.1 is NOT used as the source
> address.  Firewalls in residential case are rarely an issue based on my
> experience if the relay uses 192.88.99.1 as the source address.

It is mentioned somwhere that there is conflicting evidence on this
point - actually it depends on whether the client is behind a stateful
firewall or not. So I think this point is covered.

> host because it will set MSS lower than 1500-40=1460B. 

I have personally experienced MSS negotiation failing in exactly this
case. Probably that is an implementation bug at the server side, and I
agree this point should be mentioned.

This however
> could be a problem if 6to4 is enabled on a router and it advertises the
> prefix on a LAN, because if it doesn't also advertise a smaller MTU,
> hosts on the LAN will use MSS=1460 and TCP MSS negotiation will fail.

Yes, certainly.

> next to the two researches on "very broken 6to4".

I'll have a look.

> document to include vendors.

That's why the first sentence of this section says
"  Although this document is aimed principally at operators, there are
   some steps that implementers and vendors of 6to4 should take."

> .. this must be removed unless there is more operational experience with
> this approach.  Hinting at the ISPs that this could be a good approach
> is very wrong if we don't know that it is actually the case.

I don't see that. We know that it cannot make things worse and might
make things better.

> informative references not direct URLs in text.

We can leave the RFC Editor to apply their preferred policy for this.

> - S 4.2 is almost two pages long.  It would be better focused with

It's a bit of a laundry list, so I am not sure what logical groupings
exist that could become subsections.

> - S 4.4: as already commented by others, remove IXP

Text will be updated.

> - S 4.5: s/suceeds/succeeds/; s/firewallls/firewalls/

Ack.

Thanks
    Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Apr 2011 08:27:58 +0300 (EEST)

> anything redundant in the explanation.

You seem to be arguing that S 2.1 is an overview of 6to4 without 
anycast and that such an overview is essential.

I'd argue that this document does not need to provide a description of 
how basic 6to4 or anycast 6to4 works; it is already described in those 
documents, and it is not essential in order to understand the rest of 
the document. The reader can get the message of the document even if 
(s)he isn't very familiar with rfc3056 or rfc3068 even without the 
details in Section 2.

> firewall or not. So I think this point is covered.

There are two different axes here - firewall and source address:

1. stateful firewall
2. stateless firewall

a. relay uses 192.88.99.1 as source
b. relay uses non-anycast as source

I'm saying that 1.b) cannot work and this is likely causing bad 
figures in Geoff's study.  1.a) can work out of the box with zero 
configuration. Therefore the point is not (only) "stateful firewall" 
but also (or mainly) source aaddress.  Both 2.a) and 2.b) are likely 
to work with roughly the same probability.

There are actually more granularity in how firewalls work, but that 
shows that using 192.88.99.1 as source is _especially important_ for 
stateful firewalls.

> agree this point should be mentioned.

I'd actually suspect that the issue is more at the client side, i.e., 
the client doesn't lower MSS based on where the default route points.

>   some steps that implementers and vendors of 6to4 should take."

I read that.  But it isn't written in the abstract or introduction. 
IMHO, either this needs to be made a first-class citizen in the 
document or it should be removed.

> I don't see that. We know that it cannot make things worse and might

Disagree.

If the concerned ISP is able to ping 192.88.99.1 and the relay will 
forward traffic from the concerned ISP's IP addresses, it is "better 
than nothing".  It is a working 3rd party service that the concerned 
ISP is disrupting.  In some countries this can even be illegal unless 
a provision is made in the contract to allow such blocking.

I agree only with the part that if:
  a) 192.88.99.1 address does not respond,
  b) does not provide 6to4 service that works, or
  c) the isp customers are all using bogonized addresses [you could 
think this as a special case of b)]

.. then it is known that, at least at that particular moment, the 
concerned ISP is no worse off by returning ICMP unreachables.

> We can leave the RFC Editor to apply their preferred policy for this.

I think you very well know that this is not RFC editor's preferred 
policy.

I feel it is irresponsible to push out text (also to the IETF LC and 
IESG) that has known editorial irregularities.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Apr 2011 12:47:52 +1200

Hi Pekka,

On 2011-04-21 17:27, Pekka Savola wrote:
> You seem to be arguing that S 2.1 is an overview of 6to4 without anycast
> and that such an overview is essential.

Yes, exactly.

> (s)he isn't very familiar with rfc3056 or rfc3068 even without the

Well, we disagree, so we'd better see what the WG Chairs think.

> I'm saying that 1.b) cannot work and this is likely causing bad figures
> in Geoff's study.  1.a) can work out of the box with zero configuration.
> Therefore the point is not (only) "stateful firewall" but also (or
> mainly) source aaddress.  Both 2.a) and 2.b) are likely to work with
> roughly the same probability.
> 

I agree with your analysis, but of course there can also be situations
where ingress filtering could cause source=192.88.99.1 to be blackholed.
So unfortunately there is no single correct answer here. I will try to
ensure that the text is clear about this.

> the client doesn't lower MSS based on where the default route points.

In the case of my own client (XP) it did seem to be signaling a smaller
MSS but the server insisted on the higher value.

> IMHO, either this needs to be made a first-class citizen in the document
> or it should be removed.

Well, I really think that is a matter of taste.

> than nothing".  It is a working 3rd party service that the concerned ISP
> is disrupting.  In some countries this can even be illegal unless a
> provision is made in the contract to allow such blocking.

You're saying that if the service is unstable or has a large latency,
the user might still be better off than using IPv4? I think there has been
a very strong consensus on the list against that view.

Again, we'd better see what the WG Chairs think.

>  c) the isp customers are all using bogonized addresses [you could think
> this as a special case of b)]
> 
> I think you very well know that this is not RFC editor's preferred policy.

Really? They raised no objection to the embedded URLs in RFC 5887, for
example. Actually the style guide discourages URLs in general, not
URLs in the main text specifically, so I only use URLs when there
is no alternative.

   Brian

---

From: Michael Newbery <[email-masked]>
Date: Fri, 22 Apr 2011 13:06:46 +1200

On 21/04/2011, at 5:27 PM, Pekka Savola wrote:

> You seem to be arguing that S 2.1 is an overview of 6to4 without anycast and that such an overview is essential.
> 
> I'd argue that this document does not need to provide a description of how basic 6to4 or anycast 6to4 works; it is already described in those documents, and it is not essential in order to understand the rest of the document. The reader can get the message of the document even if (s)he isn't very familiar with rfc3056 or rfc3068 even without the details in Section 2.

That way lies madness and ITU standards documentation :)

As a personal preference, I VERY much prefer to have a short summary inline rather than having to jump to a linked document, or worse yet a chain of linked documents.

---

From: Fred Baker <[email-masked]>
Date: Thu, 21 Apr 2011 19:22:01 -0700

> Well, we disagree, so we'd better see what the WG Chairs think.

Speaking for myself, I have no issue in this regard with the document as it stands.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 22 Apr 2011 11:14:38 +0200

Inline: GV> 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Michael Newbery
Sent: 22 April 2011 03:07
To: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC

>>> Carpenter, so text on that is not very useful (most of 1st paragraph
of

As a personal preference, I VERY much prefer to have a short summary
inline rather than having to jump to a linked document, or worse yet a
chain of linked documents.

GV> +1

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Apr 2011 08:58:14 +0300 (EEST)

> Again, we'd better see what the WG Chairs think.

Let's take a step back.  You're arguing that in such a case, the user 
is better off if the ISP returns an ICMP unreachable in response to 
packets sent to 192.88.99.1, even though we don't even have practical 
experience if that even works (i.e. disables 6to4).

I would object to this regardless, because you're recommending 
bit-pipe ISPs to start doing things on behalf of their end-customers 
perceived best interests.  "The middle" mucking in end-to-end 
communication is a big no-no in my book.

But I have double objection to this because we don't even know if 
the scheme you propose works and that it doesn't cause unintentional 
side-effects.

I'd like to see where is this mythical unstable or large latency 6to4 
relay? I haven't seen any in my vantage point.  Those that suffer from 
one could just set up a working one per the instructions in the draft 
and their customers' perceived problems (with this regard) would go 
away.

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 15:51:05 +0900

> communication is a big no-no in my book.

are you speaking of 6to4 relays?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Apr 2011 09:56:51 +0300 (EEST)

> are you speaking of 6to4 relays?

No, I'm speaking of ISPs returning ICMP unreachables or blackholing 
destination IPs of their own choosing.

I'd assume most users expect that the ISP is not in the business of 
filtering content and whatnot.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Apr 2011 19:16:36 +1200

On 2011-04-26 17:58, Pekka Savola wrote:
> Let's take a step back.  You're arguing that in such a case, the user is
> better off if the ISP returns an ICMP unreachable in response to packets
> sent to 192.88.99.1, even though we don't even have practical experience
> if that even works (i.e. disables 6to4).
> 
> I would object to this regardless, because you're recommending bit-pipe
> ISPs to start doing things on behalf of their end-customers perceived
> best interests.  "The middle" mucking in end-to-end communication is a
> big no-no in my book.
> 
> But I have double objection to this because we don't even know if the
> scheme you propose works and that it doesn't cause unintentional
> side-effects.
> 
> relay? I haven't seen any in my vantage point. 

I have.

 Those that suffer from
> and their customers' perceived problems (with this regard) would go away.

Yes, but if they don't want to do that, I believe we should suggest an alternative
approach. I have tuned the language in response to your comments, to make
it clear that it's an individual ISP's choice. The IETF has never done well
by *telling* ISPs what to do...

   Brian