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

[Tariq Saraj <[e-mail]>]

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]> wrote:
>
> Send v6ops mailing list submissions to
>         [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]
>
> You can reach the person managing the list at
>         [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]>
> To: "t.petch" <[e-mail]>, "Fred Baker (fred)" <[e-mail]>,
> "[e-mail]" <[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]]
> >Sent: Thursday, December 11, 2014 1:39 AM
> >To: Sheng Jiang; Fred Baker (fred); [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]>
> >To: "t.petch" <[e-mail]>; "Fred Baker (fred)"
> ><[e-mail]>; <[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]>
> >> >To: <[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]).
> >> >
> >> >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] 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]
> >> >> https://www.ietf.org/mailman/listinfo/v6ops
> >> >>
> >> >
> >> >_______________________________________________
> >> >v6ops mailing list
> >> >[e-mail]
> >> >https://www.ietf.org/mailman/listinfo/v6ops
> >>
>
>
>
> ---------- Forwarded message ----------
> From: Keith Moore <[e-mail]>
> To: [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]>
> To: Jeroen Massar <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Cc: "[e-mail]" <[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]
>
>
>
>
> ---------- Forwarded message ----------
> From: Brian E Carpenter <[e-mail]>
> To: Keith Moore <[e-mail]>
> Cc: [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]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

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