Re: [v6ops] v6ops Digest, Vol 52, Issue 41

["Templin, Fred L" <[e-mail]>]

Hi Tariq,

Although the document uses the term “NBMA”, AERO does include provisions
for multicasting:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

AERO can serve as a replacement for both 6to4 and 6rd.

Thanks – Fred
[e-mail]

From: v6ops [mailto:[e-mail]] On Behalf Of Tariq Saraj
Sent: Saturday, December 13, 2014 11:18 AM
To: [e-mail]
Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41

There are some issues with 6rd as well, IPv6 with all its powerful features is still under critical objections in academia just because of the urgency shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly mentioned that it cannot support multicast at layer-3, on the other end 6rd claimed that multicast can be provided, my question is that while standardizing 6rd which at that time was just supporting unicast traffic traversing across IPv4 network and its still not matured enough to provide multicast support yet in its functionality other than using some proxy support for multicast traffic. why It was standardized ? a common university level student is considering IPv6 nothing more than just a large address space. The support for multicast traffic is increasing every day at application level. My request at this forum is to consider 6rd along with the 6to4 so that in future both of these protocols not to become a part of any network device. I personally feels that instead of supporting to promote the IPv6 both of these protocols are becoming obstacles in this regards. I prefer using GRE over these automatic tunneling mechanisms at least GRE supports multicast on network layer and let the application program to design his/her application in more different ways.

On Fri, Dec 12, 2014 at 1:00 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Send v6ops mailing list submissions to
        [e-mail]<mailto:[e-mail]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/v6ops
or, via email, send a message with subject or body 'help' to
        [e-mail]<mailto:[e-mail]>

You can reach the person managing the list at
        [e-mail]<mailto:[e-mail]>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of v6ops digest..."

Today's Topics:

   1. Re: Working Group Administrivia (Sheng Jiang)
   2. Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
      (Keith Moore)
   3. Re: PMTUD forever, was: MTUs on the general Internet
      (Templin, Fred L)
   4. Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
      (Brian E Carpenter)


---------- Forwarded message ----------
From: Sheng Jiang <[e-mail]<mailto:[e-mail]>>
To: "t.petch" <[e-mail]<mailto:[e-mail]>>, "Fred Baker (fred)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc:
Date: Thu, 11 Dec 2014 02:24:24 +0000
Subject: Re: [v6ops] Working Group Administrivia
Hi, Tom,

Thanks for your offer.

Review and comments would be very helpful for us to improve. Following the latest discussion, there are two actions we are planning: A) focus on the implementation divergence rather than a protocol definition problem statement. The most of contents are already in the current document. It just needs a little bit reorganizing and rewording. B) some addition investigation or experiments, e.g. both DHCPv6 and ND have DNS configuration.

If you are interested to contribute, you are certainly welcome.

Best regards,

Sheng

>-----Original Message-----
>From: t.petch [mailto:[e-mail]<mailto:[e-mail]>]
>Sent: Thursday, December 11, 2014 1:39 AM
>To: Sheng Jiang; Fred Baker (fred); [e-mail]<mailto:[e-mail]>
>Subject: Re: [v6ops] Working Group Administrivia
>
>Sheng
>
>If I read the e-mail addresses aright, you are the editor of
>draft-ietf-v6ops-dhcpv6-slaac-problem
>What do you want (that I might be able to do) bofore this is ready for
>WG Last Call?
>
>Tom Petch
>
>
>----- Original Message -----
>From: "Sheng Jiang" <[e-mail]<mailto:[e-mail]>>
>To: "t.petch" <[e-mail]<mailto:[e-mail]>>; "Fred Baker (fred)"
><[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>
>Sent: Monday, December 08, 2014 2:18 AM
>Subject: RE: [v6ops] Working Group Administrivia
>
>
>> >As Brian says in his note,
>> >
>> >2014-10-27           draft-ietf-v6ops-dhcpv6-slaac-problem
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
>> >
>> >addresses a known problem and I think it would be remiss of the IETF
>not
>> >to have this documented
>>
>> Fully agreed. My read from the latest meeting response is the problem
>should be document and know by operators and implementors. The
>controversial part is not this draft, but the follow up of this draft:
>>
>> 1) The solution (protocol level) is not belong to v6ops WG.
>>
>> 2) The real debate is Whether v6ops should produce an operational
>guidelines for operators to avoid this issue. Personally, I think it is
>helpful and belong to this WG, but it seems the WG does not reach
>consensus on this.
>>
>> Best regards,
>>
>> Sheng
>>
>> >Tom Petch
>> >
>> >
>> >----- Original Message -----
>> >From: "Fred Baker (fred)" <[e-mail]<mailto:[e-mail]>>
>> >To: <[e-mail]<mailto:[e-mail]>>
>> >Sent: Friday, December 05, 2014 6:17 PM
>> >Subject: [v6ops] Working Group Administrivia
>> >
>> >
>> >Joel, Lee, and I spoke this morning about the status of the working
>> >group and various drafts in it. I’d like to gauge working group
>> >consensus on the status of a number of working group drafts that have
>> >either expired or otherwise should no longer be considered working
>group
>> >drafts. Your opinions, pro or con (such as “I’m fine with all that
>but
>> >think we should still be considering draft-whatever”), please:
>> >
>> >We think that the following can be safely set aside, by having the
>> >secretariat record (and show in the data tracker) that they are no
>> >longer working group drafts. They have expired, and are not currently
>> >being pursued:
>> >
>> >2003-01-13                     draft-ietf-v6ops-ipv4survey
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/
>> >2003-02-14                 draft-ietf-v6ops-ipv4survey-gen
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/
>> >2004-07-20                  draft-ietf-v6ops-v6onbydefault
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/
>> >2007-02-27             draft-ietf-v6ops-routing-guidelines
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/
>> >2007-03-28              draft-ietf-v6ops-campus-transition
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/
>> >2008-05-13         draft-ietf-v6ops-nat64-pb-statement-req
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-req
>/
>> >2011-07-26             draft-ietf-v6ops-v4v6tran-framework
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/
>> >2013-08-14                draft-ietf-v6ops-monitor-ds-ipv6
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/
>> >
>> >We think that draft-ietf-v6ops-balanced-ipv6-security, in its current
>> >state, is a deployment report, primarily from Swisscom. While the
>> >working group expressed interest in guidance on firewall
>configuration,
>> >this isn’t it. We think it should no longer be a working group draft,
>> >and invite the authors to submit it to the independent stream as a
>> >deployment report (<[e-mail]<mailto:[e-mail]>).
>> >
>> >2013-12-06         draft-ietf-v6ops-balanced-ipv6-security
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security
>/
>> >
>> >Although the working group expressed interest in the following and
>the
>> >authors have been working hard on them, we think the working group is
>no
>> >longer interested in these, and so they should be returned to the
>> >authors and not recorded or treated as working group drafts.
>> >
>> >2014-09-18                 draft-ietf-v6ops-design-choices
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/
>> >2014-10-27           draft-ietf-v6ops-dhcpv6-slaac-problem
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
>> >2014-10-27      draft-ietf-v6ops-ula-usage-recommendations
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendati
>o
>> >ns/
>> >
>> >Speaking for myself, if I have any question of the above, it is on
>only
>> >one of these.
>> >
>> >If any draft has its "WG Draft" status revoked, it will still be
>> >available from the IETF website as far as I know, but subsequent
>> >revisions should be named as individual submissions to a working
>group,
>> >draft-<author>-<wg>-<subject> or individual submissions to the IETF,
>> >draft-<author>-<subject>. It would be good if the authors would send
>a
>> >note to [e-mail]<mailto:[e-mail]> indicating that the old draft name
>were
>> >replaced by the new draft name, so that the revision history is
>tracked
>> >appropriately.
>> >
>> >Opinions?
>> >
>> >
>> >
>> >
>>
>>-----------------------------------------------------------------------
>-
>> >--------
>> >
>> >
>> >>
>> >>
>> >
>> >
>>
>>-----------------------------------------------------------------------
>-
>> >--------
>> >
>> >
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> [e-mail]<mailto:[e-mail]>
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>> >>
>> >
>> >_______________________________________________
>> >v6ops mailing list
>> >[e-mail]<mailto:[e-mail]>
>> >https://www.ietf.org/mailman/listinfo/v6ops
>>



---------- Forwarded message ----------
From: Keith Moore <[e-mail]<mailto:[e-mail]>>
To: [e-mail]<mailto:[e-mail]>
Cc:
Date: Thu, 11 Dec 2014 10:42:54 -0500
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
Mumble.  I support the deprecation of 192.88.99.1 as a means to find 6to4 relays.   But this document still contains so many inaccurate and misleading statements beyond that, including perhaps some statements that were not present in earlier versions (though I haven't taken the time to check yet), that I don't believe it should be published in its current form. Again, this is a document quality issue, not an issue with the basic underlying recommendation.

Most of the problems with this document are things that I have already mentioned in connection with earlier versions of this document.

Keith




---------- Forwarded message ----------
From: "Templin, Fred L" <[e-mail]<mailto:[e-mail]>>
To: Jeroen Massar <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thu, 11 Dec 2014 16:10:44 +0000
Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> More on what I said the other day, there are two magic numbers that tunnels
> need to concern themselves with: 1280 and 1500. Accommodating all packets
> within that size range while placing no explicit upper bound for accommodating
> larger packets is what is being proposed. In other words, no MTU clamping.

Have we reached conclusion on this, and can it now be considered "case closed"?

Remember - "take care of the smalls, and let the bigs take care of themselves":

https://datatracker.ietf.org/doc/draft-templin-aerolink/
https://datatracker.ietf.org/doc/draft-templin-aeromin/

Thanks - Fred
[e-mail]<mailto:[e-mail]>




---------- Forwarded message ----------
From: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>
To: Keith Moore <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Date: Fri, 12 Dec 2014 08:23:12 +1300
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
Keith, please, you need to be specific about what you think is
inaccurate or misleading, line by line, in this version. There's
nothing we can do with a general criticism like that.

We have made numerous changes, some of them in response to your
comments, but of course in some cases your comments were at
variance with other peoples' comments. Of course, there were a
lot of messages, many of them completely orthogonal to the text
of the draft, so we may well have missed some of the relevant ones.

Regards
   Brian

On 12/12/2014 04:42, Keith Moore wrote:
> Mumble.  I support the deprecation of 192.88.99.1 as a means to find
> 6to4 relays.   But this document still contains so many inaccurate and
> misleading statements beyond that, including perhaps some statements
> that were not present in earlier versions (though I haven't taken the
> time to check yet), that I don't believe it should be published in its
> current form. Again, this is a document quality issue, not an issue with
> the basic underlying recommendation.
>
> Most of the problems with this document are things that I have already
> mentioned in connection with earlier versions of this document.
>
> Keith
>
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
>



_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops


--
Regards
Tariq Saraj
Center for Research in Networks and Telecom (CoReNeT)