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

From: Tariq Saraj <[email-masked]>
Date: Sun, 14 Dec 2014 00:18:00 +0500

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

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

---

From: Mark Andrews <[email-masked]>
Date: Sun, 14 Dec 2014 09:04:05 +1100

In message <CAAdbxrpgsdJJ0exP435JSB=m7RV=[email-masked]>
, Tariq Saraj writes:
> support for multicast traffic. why It was standardized ?

6to4 and 6rd are interim solutions for delivering IPv6 over IPv4.
They were standardized so that manufactures could ship products
that interoperate.

Engineering is all about trade offs.  With 6to4 and 6rd it is about
delivering IPv6 unicast in a timely manner while waiting for the
intermediate network components to be upgraded to support IPv6.

If you need IPv6 multicast then you need to arrange for it to be
delivered.  You can still run multicast tunnels over 6to4 and 6rd
if you need to.  They just don't supply multicast natively.

I suspect you will find you will need to do this even with native
IPv6 as many ISP's are in the business of delivering global multicast
traffic.

> a common

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Dec 2014 16:15:16 +0000

Hi Tariq,

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

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

Thanks – Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Tariq Saraj
Sent: Saturday, December 13, 2014 11:18 AM
To: [email-masked]
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, <[email-masked]<mailto:[email-masked]>> wrote:
Send v6ops mailing list submissions to
        [email-masked]<mailto:[email-masked]>

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
        [email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
        [email-masked]<mailto:[email-masked]>

Today's Topics:

---------- Forwarded message ----------
From: Sheng Jiang <[email-masked]<mailto:[email-masked]>>
To: "t.petch" <[email-masked]<mailto:[email-masked]>>, "Fred Baker (fred)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

Best regards,

Sheng

>From: t.petch [mailto:[email-masked]<mailto:[email-masked]>]
>To: Sheng Jiang; Fred Baker (fred); [email-masked]<mailto:[email-masked]>
>From: "Sheng Jiang" <[email-masked]<mailto:[email-masked]>>
>To: "t.petch" <[email-masked]<mailto:[email-masked]>>; "Fred Baker (fred)"
><[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
>> >From: "Fred Baker (fred)" <[email-masked]<mailto:[email-masked]>>
>> >To: <[email-masked]<mailto:[email-masked]>>
>> >deployment report (<[email-masked]<mailto:[email-masked]>).
>> >
>> >note to [email-masked]<mailto:[email-masked]> indicating that the old draft name
>were
>> >> [email-masked]<mailto:[email-masked]>
>> >[email-masked]<mailto:[email-masked]>

---------- Forwarded message ----------
From: Keith Moore <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
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" <[email-masked]<mailto:[email-masked]>>
To: Jeroen Massar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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
> 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":

Thanks - Fred
[email-masked]<mailto:[email-masked]>

---------- Forwarded message ----------
From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
To: Keith Moore <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Date: Fri, 12 Dec 2014 08:23:12 +1300
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt

Regards
   Brian

On 12/12/2014 04:42, Keith Moore wrote:
> [email-masked]<mailto:[email-masked]>

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

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 15 Dec 2014 19:01:13 +0100

Hi,

> support for multicast traffic. why It was standardized ? 

There is no wide-area multicast anyway.  So why bother if a closed user
group decides to deploy a stopgap technology to enable IPv6 access.

And, when speaking about academia: do they have a "how to not write e-mail"
class there?  Like, "take a full digest with lots of unrelated mail in it,
and write a top posting on top of it"?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Fred Baker <[email-masked]>
Date: Mon, 15 Dec 2014 17:19:04 -0800

> On Dec 13, 2014, at 11:18 AM, Tariq Saraj <[email-masked]> wrote:
> 
> 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 ? 

Without detracting from Gerd and other’s comments, the primary issue that 6rd addressed was a deployment issue. Suppose, if you will, that everything in your network is IPv6-capable and has IPv6 turned up, with the exception of one kind of equipment such as a BRAS. What you might like to do is configure (easily, for some definition of that term) an IPv4 tunnel to jump over that device to your customer, enabling you to give the customer an IPv6 *service* even though you can’t today given him *native*service*. ISATAP and 6to4 similarly were intended to provide a way to deploy IPv6 as a service before native IPv6 was feasible.

Where we are at today, there isn’t really a lot of equipment that one would have to “jump over”. Hence, patience with those solutions is becoming a little frayed. If they present a limitation, such as lack of multicast service, improving the bandaid is throwing good money after bad. Folks today would suggest that you take the next step, of deploying native IPv6 service.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 18 Dec 2014 22:03:32 +0000 (UTC)

----- Original Message -----
> From: Gert Doering <[email-masked]>
> To: Tariq Saraj <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, 16 December 2014, 5:01
> There is no wide-area multicast anyway.

Technically it should be universal, as DAD uses multicast and DAD is mandatory (except for anycast addresses), which should include tunnels.

Links are supposed to provide multicast capability or emulate it to support Neighbor Discovery:

RFC4861:

"2.2.  Link Types

Different link layers have different properties.  The ones of concern
to Neighbor Discovery are:

multicast capable
- a link that supports a native mechanism at the link
layer for sending packets to all (i.e., broadcast)
or a subset of all neighbors.

point-to-point - a link that connects exactly two interfaces.  A
point-to-point link is assumed to have multicast
capability and a link-local address.

non-broadcast multi-access (NBMA)
- a link to which more than two interfaces can attach,
but that does not support a native form of multicast
or broadcast (e.g., X.25, ATM, frame relay, etc.).
Note that all link types (including NBMA) are
expected to provide multicast service for
applications that need it (e.g., using multicast
servers).  However, it is an issue for further study
whether ND should use such facilities or an
alternate mechanism that provides the equivalent
multicast capability for ND."

>  So why bother if a closed user

---

From: Gert Doering <[email-masked]>
Date: Fri, 19 Dec 2014 12:38:12 +0100

Hi,

> Technically it should be universal, as DAD uses multicast and DAD is mandatory (except for anycast addresses), which should include tunnels.

This is not *wide-area* multicast, but link-local.

Slight difference.

Gert Doering
        -- NetMaster

---

From: Tariq Saraj <[email-masked]>
Date: Fri, 19 Dec 2014 19:36:37 +0500

Smith what you are pointing is all at link level and purely related to
IPv6, Discussion is related Multicast support in Hybrid IPv4-IPv6 Internet
at IP layer (i.e. IPvX-IPvY-IPvX)

On Fri, Dec 19, 2014 at 3:03 AM, Mark ZZZ Smith <[email-masked]>
wrote:
> Technically it should be universal, as DAD uses multicast and DAD is
> mandatory (except for anycast addresses), which should include tunnels.
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 20 Dec 2014 01:21:45 +0000 (UTC)

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>
> Cc: Gert Doering <[email-masked]>; Tariq Saraj <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Friday, 19 December 2014, 22:38

Perhaps I'm misunderstanding what you're saying, however 6to4 creates a single NBMA link. As per the RFC4861 text I referenced, NBMA links should emulate a multicast capability. An Internet search found the following draft that seems to specify how multicast was to be emulated over 6to4:

"Support for Multicast over 6to4 Networks"
https://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast-01

There seems to be a fairly common belief that the ability to IPv6 multicast across a link is optional, because I think in IPv4 it was.

It seems to me that the IPv6 approach is that the minimum characteristics IPv6 expects of links is to be able to unicast and multicast across them. If a link doesn't support multicast then multicast capability is expected to be emulated below or within the lower part of the IPv6 layer - which is what the text I quoted from RFC4861 says about emulating multicast on point-to-point and NBMA links.

I think the advantage of the IPv6 approach is that there doesn't have to be link capability specific handling with IPv6 itself - all links appear to have the same set of unicast and multicast capabilities. Consequently, any of the standard IPv6 mechanisms, such as Neighbor Discovery DAD or Neighbor Discovery Address Resolution, should work and work the same way over all link types, rather than being different depending on whether the link natively supports multicast or not. Applications that use multicast of any scope should also just work regardless of the underlying link type. So, for example, Multicast DNS, using link-local multicasts, should work over 6to4 NBMA links as seamlessly as it does over 802.3 or 802.11 links.

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 20 Dec 2014 01:56:36 +0000 (UTC)

>________________________________
> From: Tariq Saraj <[email-masked]>
>To: Mark ZZZ Smith <[email-masked]>; [email-masked] 
>Sent: Saturday, 20 December 2014, 1:36
>Smith what you are pointing is all at link level and purely related to IPv6, Discussion is related Multicast support in Hybrid IPv4-IPv6 Internet at IP layer (i.e. IPvX-IPvY-IPvX)  

So the layer below the network layer is the link-layer.

IPv6 is the network layer protocol, and therefore any protocols directly below it from the IPv6 point of view are either literally or conceptually link-layer protocols.

IPv6 encapsulated in IPv4 means that IPv4 is being used as by IPv6 as a link-layer protocol, and is constructing a single link-layer link for IPv6 to operate over.

IPv6 expects link-layers to provide or emulate unicast and multicast capabilities. If IPv4 is being used to construct a link-layer for IPv6 to operate over, then it should provide or emulate a link-layer unicast and multicast capability.

Once the (IPv4 constructed) link-layer provides or emulates both a unicast and multicast capability, there is nothing special about it from the IPv6 point of view, and I don't think there needs to be any IPv6-specific handling of this situation. If the link-layer IPv4 is further encapsulated in other IP encapsulations ("i.e. IPvX-IPvY-IPvX"), that is all hidden within the link-layer or below it and not visible or relevant to IPv6 operation at the network layer. Making IPv6 aware of that would be a layer violation.

More broadly, what has been missing from 6to4 was the emulation of a multicast capability, meaning that 6to4 currently doesn't really meet IPv6's minimum link-layer link capability requirements. It seems some work was done on emulating it in the following draft, but it didn't advance for some reason or another:

Support for Multicast over 6to4 Networks
https://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast-01

>
>On Fri, Dec 19, 2014 at 3:03 AM, Mark ZZZ Smith <[email-masked]> wrote:
>
>>
>>
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Dec 2014 15:58:02 +1300

> IPv6 expects link-layers to provide or emulate unicast and multicast capabilities. If IPv4 is being used to construct a link-layer for IPv6 to operate over, then it should provide or emulate a link…

This was of course exactly the basis for 6over4
(http://tools.ietf.org/html/rfc2529).
That was intended for single administrative domains, where IPv4
multicast was a not
unreasonable but rather optimistic assumption in 1999.

> https://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast-01

14 years ago, multicast deployment was low on the list of IPv6 priorities.

   Brian

---

From: Gert Doering <[email-masked]>
Date: Sun, 21 Dec 2014 13:10:42 +0100

Hi,

On Sat, Dec 20, 2014 at 01:56:36AM +0000, Mark ZZZ Smith wrote:
> More broadly, what has been missing from 6to4 was the emulation
> of a multicast capability, meaning that 6to4 currently doesn't
> really meet IPv6's minimum link-layer link capability requirements.

So should we deprecate 6to4, then?

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Dec 2014 07:37:38 +1300

> So should we deprecate 6to4, then?

I would agree to that only if we deprecate RFC 6214 for the same reason.

   Bian

---

From: Gert Doering <[email-masked]>
Date: Sun, 21 Dec 2014 19:52:51 +0100

Hi,

> I would agree to that only if we deprecate RFC 6214 for the same reason.

Which, amazingly, has a section on Multicast!

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Dec 2014 16:47:39 +0000

> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Sunday, December 21, 2014 10:38 AM
> To: Gert Doering
> Cc: Tariq Saraj; [email-masked]

Or even RFC5214, for that matter...

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Dec 2014 16:51:59 +0000

> Sent: Friday, December 19, 2014 6:58 PM
> To: Mark ZZZ Smith
> Subject: [v6ops] Multicast support [was: v6ops Digest, Vol 52, Issue 41]
> 
> >> Smith what you are pointing is all at link level and purely related to IPv6, Discussion is related Multicast support in Hybrid IPv4-IPv6
> Internet at IP layer (i.e. IPvX-IPvY-IPvX)
> >
> >>
> >
> > IPv6 expects link-layers to provide or emulate unicast and multicast capabilities. If IPv4 is being used to construct a link-layer for IPv6
> to operate over, then it should provide or emulate a link-layer unicast and multicast capability.
> 

BTW, this approach is adopted also for AERO.

Thanks - Fred

> > Once the (IPv4 constructed) link-layer provides or emulates both a unicast and multicast capability, there is nothing special about it
> from the IPv6 point of view, and I don't think there needs to be any IPv6-specific handling of this situation. If the link-layer IPv4 is
> further encapsulated in other IP encapsulations ("i.e. IPvX-IPvY-IPvX"), that is all hidden within the link-layer or below it and not visible
> or relevant to IPv6 operation at the network layer. Making IPv6 aware of that would be a layer violation.
> >
> >
> > More broadly, what has been missing from 6to4 was the emulation of a multicast capability, meaning that 6to4 currently doesn't
> really meet IPv6's minimum link-layer link capability requirements. It seems some work was done on emulating it in the following
> draft, but it didn't advance for some reason or another:
> >