headers
Wojciech Dec | 2 Aug 2010 15:55
Picon
Favicon

Re: draft-gundavelli-v6ops-l2-unicast WGLC


On 02/08/2010 15:24, "Wes Beebee" <wbeebee@...> wrote:

>> As this draft is changing what has been a fundamental and fixed
>> assumption for a very long time (i.e. layer 3 multicast always equals
>> layer 2 multicast), I think it's important that use cases supporting it
>> are very clear in what they're trying to achieve and why allowing
>> multicast layer 3 addresses maps to layer 2 unicast is the best way to
>> solve those problems. A bit more detail in these use cases would help.
> 
> As I understand it, the use case is a fast RA handover when a link first
> comes up.  They don't want to wait for an NS(DAD) (otherwise they could just
> use the LLA from the NS(DAD) as the RA destination, problem solved) - so
> they want to be able to send packets without having a L3 unicast
> destination.  L3 multicast allows them to do that - but then they need L2
> unicast because they really want to send a unicast packet without the L3
> unicast address.  The L3 multicast address is just being used to make sure
> that the node processes the packet.

That is not quite so. There are numerous L2 protocols that do not map a L3
mcast to L2, eg PPP. One could even say PPPoE. The technique has been used
for years in Wifi 802.11 too, besides regular IPv4 over ethernet which is
implied as the only L2 here.

> 
> The problem is that this assumption of L3 multicast comes with L2 multicast
> is a very deeply imbedded assumption in current implementations - and it
> would take analysis of the whole box including not only the software, but
> also the hardware, in order to see if this can be supported.  As far as I
> know, the software analysis has been done for some implementations, but the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Hinden | 5 Aug 2010 23:40
Picon

Re: Avoiding the terminology confusion with NAT66

Randy,

On Aug 3, 2010, at 2:43 PM, Randy Bush wrote:

>>> If so, I encourage Margaret and Fred to not use NAT66 for their
>>> specification.  Rather, "IPv6 Prefix Rewriting".  "6pr" almost rolls
>>> off the tongue.
>> Other names could do it too, e.g. PT66 for prefix translation, or SPT
>> for Stateless Prefix Translation, whatever Margaret and:or the
>> majority would prefer, provided it isn't NAT66.
> 
> since we're into deceptive marketing, why not call it chocolate ice
> cream?

I think it's the other way around.  To use your example, NAT66 is a name many people are using to describe all
flavors of ice cream.  Margaret's draft is a particular flavor of ice cream.  It would be better to call it
chocolate ice cream :-)

Bob
Permalink | Reply | 5 comments |
headers
Bob Hinden | 6 Aug 2010 03:39
Picon

Re: Avoiding the terminology confusion with NAT66

On Thu, Aug 5, 2010 at 5:46 PM, Randy Bush <randy@...> wrote:
>> I think it's the other way around.  To use your example, NAT66 is a
>> name many people are using to describe all flavors of ice cream.
>> Margaret's draft is a particular flavor of ice cream.  It would be
>> better to call it chocolate ice cream :-)
>
> if it translates addresses, that is sufficiently significant that NAT
> should be in the name.  so chocoNAT is fine with me.  or maybe cocoNAT
>

How about pomegraNATe :-)

Bob
Permalink | Reply | 2 comments |
headers
Mark Smith | 6 Aug 2010 17:58

Re: Avoiding the terminology confusion with NAT66

On Thu, 5 Aug 2010 18:39:52 -0700
Bob Hinden <bob.hinden@...> wrote:

> On Thu, Aug 5, 2010 at 5:46 PM, Randy Bush <randy@...> wrote:
> >> I think it's the other way around.  To use your example, NAT66 is a
> >> name many people are using to describe all flavors of ice cream.
> >> Margaret's draft is a particular flavor of ice cream.  It would be
> >> better to call it chocolate ice cream :-)
> >
> > if it translates addresses, that is sufficiently significant that NAT
> > should be in the name.  so chocoNAT is fine with me.  or maybe cocoNAT
> >
> 
> How about pomegraNATe :-)
> 

DefiNATely!

> Bob
>
Permalink | Reply | 0 comments |
headers
james woodyatt | 6 Aug 2010 20:31
Picon
Favicon

Re: draft-ietf-v6ops-cpe-simple-security-12.txt feedback

On Jul 28, 2010, at 01:00, Toerless Eckert wrote:
> 
> Not quite sure what you mean. I would like application meant to be written
> for home/SMB networks to be written to use at most site-local IPv6 multicast
> group address scopes.

That's not in the ambit of the draft.

The draft recommends a DEFAULT multicast scope boundary of organization-local because we think it will be
very rare for a subscriber and their service provider to be separate sites within the *same*
organization, and moreover, we do not think that the DEFAULT should be set so that subscribers are all
expected to be within the same organization unless they actively take steps to separate themselves by
reconfiguring the multicast scope boundary.

Setting the DEFAULT multicast scope boundary to site-local, instead of organization-local, would be
profoundly wrong-headed.  I would object vigorously to making the change to the draft you propose.

> When such an application is then put into an
> enterprise network it is most likely to work comparably because it will
> be constrained to a site of the enterprise, like an office, which although
> usually larger in size than todays home networks, will still be sufficiently
> small in size to make ASM application fairly well workable.

I get that you're worried about application developers who are unsure what multicast scope to use, and who
might see this document and mistakenly think, "Hey! I better use organization-local scope so I get the
widest distribution possible in home networks without extending beyond residential gateway."  But
those application developers are A) mistaken, B) not our problem, and C) unsolvable.

Any developer who uses organization-local multicast scope when they really mean to use site-local, or
vice-versa, is just plain wrong.  If a routed internetwork at a residential subscriber contains
(Continue reading)

Permalink | Reply | 18 comments |
headers
james woodyatt | 6 Aug 2010 20:49
Picon
Favicon

Re: [MBONED] draft-ietf-v6ops-cpe-simple-security-12.txt feedback

On Jul 28, 2010, at 06:31, Tim Chown wrote:

> I agree that 3.1 REC-2 should say site-local scope is the default for the context of this draft (CPE devices
in homes and small offices).

See my previous message on this topic for my response to that proposal.

> The provider would most likely use organisation-local to scope multicast within its whole network.

As well they should do so for their private use, c.f. RFC 2365.

Setting the DEFAULT multicast scope boundary at site-local would extend service provider private
multicast beyond demarcations into their subscriber networks.  For that reason, service providers will
certainly expect to use organization-local zone boundary edge routers for the same reason we recommend
that residential gateways be organization-local zone boundary routers.

The first-mile link is an organizational zone boundary.  I don't understand why this is a point of such
confusion.  Or do we really not like the idea that subscribers are separate organizations from their
service providers?  "We are the Internet company.  All your base are belong to us!"

--
james woodyatt <jhw@...>
member of technical staff, communications engineering
Permalink | Reply | 0 comments |
headers
Fred Baker | 6 Aug 2010 20:58
Picon
Favicon

Re: draft-ietf-v6ops-cpe-simple-security-12.txt feedback


On Aug 6, 2010, at 8:31 PM, james woodyatt wrote:

> On Jul 28, 2010, at 01:00, Toerless Eckert wrote:
>> 
>> Not quite sure what you mean. I would like application meant to be written
>> for home/SMB networks to be written to use at most site-local IPv6 multicast
>> group address scopes.
> 
> That's not in the ambit of the draft.
> 
> The draft recommends a DEFAULT multicast scope boundary of organization-local because we think it will
be very rare for a subscriber and their service provider to be separate sites within the *same*
organization, and moreover, we do not think that the DEFAULT should be set so that subscribers are all
expected to be within the same organization unless they actively take steps to separate themselves by
reconfiguring the multicast scope boundary.
> 
> Setting the DEFAULT multicast scope boundary to site-local, instead of organization-local, would be
profoundly wrong-headed.  I would object vigorously to making the change to the draft you propose.

Dumb question, chair hat off...

In the absence of a deployed multicast routing protocol, I would be surprised at the use use of anything
beyond link-local multicast. We don't have an algorithm that will correctly route a multicast in a wider
scope (eg, deliver exactly once barring random loss), and we don't have an algorithm besides route
filtering in a routing protocol that will contain a multi-subnet multicast within any specific boundary.

As a result, in a SMB/SOHO/Residential environment and for that matter any environment, I would expect
multicasts to be *link-local* in scope apart from configuration - at minimum configuration of a
multicast routing protocol and appropriate route filters.
(Continue reading)

Permalink | Reply | 16 comments |
headers
Simon Leinen | 6 Aug 2010 21:40
X-Face
Picon
Favicon
Gravatar

Re: Avoiding the terminology confusion with NAT66

> How about pomegraNATe :-)

As in "Prefix-Only Modification for Enhanced Guidance,
which Ran^Hdicals Accuse of Nasty Address-Torturing Evilness"?
--

-- 
Simon.
Permalink | Reply | 0 comments |
headers
james woodyatt | 6 Aug 2010 22:20
Picon
Favicon

Re: draft-ietf-v6ops-cpe-simple-security-12.txt feedback

On Aug 6, 2010, at 11:58, Fred Baker wrote:
> 
> Why are site-local or organization-local even on the table?

An excellent question. In light of the absence, which you note, of any kind of multicast routing to/from
residential networks, it seems to me that service provider edge routers are-- in actual practice--
global multicast zone boundaries today. But that need not always be the case. Call me a dreamer, but I'm not
willing to stand up and recommend that we brick up the residential side of the first-mile multicast link
just yet.

I'm really not sure why people seem to think that subscribers ought to be lumped into the same
organizational zone as their service provider. I must need to be educated about operational
considerations again.

--
james woodyatt <jhw@...>
member of technical staff, communications engineering
Permalink | Reply | 14 comments |
headers
Mark Smith | 7 Aug 2010 02:49

Re: draft-ietf-v6ops-cpe-simple-security-12.txt feedback

On Fri, 6 Aug 2010 13:20:03 -0700
james woodyatt <jhw@...> wrote:

> On Aug 6, 2010, at 11:58, Fred Baker wrote:
> > 
> > Why are site-local or organization-local even on the table?
> 
> An excellent question. In light of the absence, which you note, of any kind of multicast routing to/from
residential networks, it seems to me that service provider edge routers are-- in actual practice--
global multicast zone boundaries today. But that need not always be the case. Call me a dreamer, but I'm not
willing to stand up and recommend that we brick up the residential side of the first-mile multicast link
just yet.
> 

There's quite a lot of IPTV interest in the .au market at the moment,
and one of the branded service wholesale IPTV providers to ISPs is
using IPv4 multicast to deliver it. The provider is originating the
multicast traffic outside the ISP networks, so in an IPv6 context I
think the scope for that traffic would need to be global. To avoid
using a global scope for that, it probably wouldn't be hard to
re-originate the content at the IPv6 layer within the ISP's network,
changing it's scope at the same time. However for that to work I think
that would mean that scope for the traffic would be organization local,
with the organisation including residential subscribers networks.

Related to this topic, the TR-124_Issue-2.pdf document from the BBF,
via Fred's ftp server, says -

"LAN.MLD.ROUTED. The device MUST default to not sending MLD messages for
scope of 0 through 8."
(Continue reading)

Permalink | Reply | 12 comments |

Gmane