fred | 1 Jul 15:00 2016
Picon

State of play

RFC Editor: AUTH48
	2016-05-27	draft-ietf-v6ops-host-addr-availability

WG: Unupdated WG Document
	2016-02-16	draft-ietf-v6ops-dhcpv6-slaac-problem
	2016-02-08	draft-ietf-v6ops-ula-usage-considerations

Individual Submission: Unupdated 
	2016-03-21	draft-ybai-v6ops-ipv6-for-openstack
	2016-03-11	draft-gont-v6ops-ipv6-ehs-packet-drops
	2016-02-27	draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
	2016-01-03	draft-xcf-v6ops-chinatelecom-deployment
	2016-01-03	draft-xli-v6ops-cernet-deployment

Individual Submission: Updated 
	2016-06-27	draft-templin-v6ops-pdhost
	2016-06-20	draft-anderson-v6ops-v4v6-xlat-prefix

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Fred Baker (fred | 28 Jun 20:42 2016
Picon

[OPSEC] IETF96 - Update your drafts & slots requests

Hi All,

 

IETF96 is approaching quickly. The first important date is Friday 8 July, by which drafts need to be updated for consumption during IETF96, according to

https://www.ietf.org/meeting/important-dates-2016.html#ietf96

 

To help plan for the IETF96 v6ops slot agenda, can we ask if you want to discuss a topic or draft during the OPSEC WG meeting.


Fred and Lee

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
"IETF Secretariat" | 24 Jun 18:00 2016
Picon

v6ops - Requested session has been scheduled for IETF 96

Dear Fred Baker,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

v6ops Session 1 (2:00:00)
    Thursday, Afternoon Session I 1400-1600
    Room Name: Potsdam I size: 300
    ---------------------------------------------

Request Information:

---------------------------------------------------------
Working Group Name: IPv6 Operations
Area Name: Operations and Management Area
Session Requester: Fred Baker

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 150
Conflicts to Avoid: 
 First Priority: 6man aqm dnsop mtgvenue opsawg opsec ospf pcp rtgwg sunset4 tsvwg
 Second Priority: tsvarea intarea lmap softwire

Special Requests:

---------------------------------------------------------

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Owen DeLong | 23 Jun 22:33 2016
Gravatar

Re: Packets with LL src and GUA dst


> On Jun 23, 2016, at 06:39 , Alexandre Petrescu <alexandre.petrescu <at> gmail.com> wrote:
> 
> 
> 
> Le 23/06/2016 à 00:47, Owen DeLong a écrit :
> [...]
>>> In all cases, the need is there: in some widespread vehicular
>>> communications there is no unicast nature of communication semantics (a
>>> car can't unicast a packet to another car) - it is all 'broadcast'.
>>> Each car broadcasts data every 1/30th seconds (30Hz) and each other car
>>> hears everybody else.  The ESSID and the dst MAC address is
>>> ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's address.
>> 
>> Then perhaps you should get a reserved multicast group number for “all cars”.
> 
> Well I wonder about the name.
> 
> The too familiar 'cars' could be more pedantic 'vehicles' or 'light vehicles'.
> 
> But 'vehicles' would look strange in the current list of nodes, routers, servers or agents
> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

I don’t care what you name it as long as it makes sense and is properly descriptive.

Cars was just an example for the sake of discussion, not an actual recommendation.

>> Then, you can use “all cars on link” for link scoped communications where
>> a LL source address would be valid and “all cars within ORG” for an ORG scoped
>> communication using a ULA source, etc.
> 
> 'ORG' - 'organization' is obviously not the right word for something ephemeral happening between a few
cars on a highway none of which being more entitled than another.

Depends. if it’s all the vehicles that belong to e.g. DHL that you are trying to reach, that could be a
perfectly legitimate use of ORG.

There are lots of other scopes to choose from as well.

Point is that with ULA SRC, agreement among the participants to forward ULA network numbers, and a proper
multicast scope, you can do what you want without breaking half the RFCs to do it.

Sure, your forwarding is now forwarding at layer 3, but that’s better in most cases anyway.

Ad-Hoc random layer 2 forwarding DOES NOT SCALE.

> 
>> There are clean ways to do this, but the proposals you have put forth so far,
>> however, are not.
> 
> I am looking for clean ways dealing with situations where it's hard to say who is the 'owner' or the control
entity which keeps track of multicast registrations in some scope.

That’s the beauty of having a registered multicast group.

The scope is a choice made at packet creation time, but the semantics of the group number remain the same
regardless of scope.

So, for example, All Nodes multicast is always ALL Nodes. You can make it All Nodes on Link, All Nodes within
ORG, All Nodes Globally, or whatever. That’s why the group ID and the Scope are separate fields in the
IPv6 Multicast address and why there’s a flag to indicate whether the Group ID is permanent/global or
valid only within the current context.

(chances of real world forwarding of multicast obviously diminish with increasing scope choice, but
that’s a separate matter).

>> There is no concept of broadcast in IPv6, so you can’t do “broadcast-only”.
>> You have to use multicast.
> 
> The word 'broadcast' can be ambiguous in this discussion.  In vehicular communications 'broadcasting'
means to send in the ether, as opposed to sending on a wired Ethernet; and it also means there is no return
path - a little bit like in 'TV broadcast'.  In a particular report, they say "DSRC operates in constant
broadcast-and-receive mode": you periodically broadcast to everyone else and always receive from
everyone else, but you can not send to just one entity.  This 'broadcast' concept of vehicles is
independent of the fact that the MAC dst address is ff:ff:ff:ff:ff:ff (MAC broadcast address).

That’s a simply stupid definition of the term and can only lead to confusion when you talk to people
involved in networking.

> But yes I agree with you when it comes to IPv6 it should use multicast addressing, not broadcast addressing.

Exactly. And it should limit the Multicast to a group assigned to the particular purpose. You might need
multiple multicast group numbers for different applications to do this right.

> So I think we should suggest to use 33:33::1 MAC address instead of the ff:ff:ff:ff:ff:ff MAC address when
IPv6 is used over these links.  I will put that in some draft.

That’s probably a good start.

Owen

_______________________________________________
v6ops mailing list
v6ops <at> ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
Fred Baker | 23 Jun 17:02 2016
Picon

IETF 96 BOFs and new topics

Just so people are aware of things you may not already be tracking ...


See you in Berlin,

Fred
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tore Anderson | 21 Jun 08:46 2016
Picon

New Version Notification for draft-anderson-v6ops-v4v6-xlat-prefix-01.txt

Hello WG,

I have just posted a new version of I-D.anderson-v6ops-v4v6-xlat-prefix.

The only change since -00 is to introduce the following paragraph in
section 5, based on a suggestion by Holger Metschulat (thank you!) that
was seconded by Alejandro Acosta:

  By default, IPv6 nodes and applications must not treat IPv6 addresses	
  within 64::/16 and outside 64:ff9b::/96 different from other globally	
  scoped IPv6 addresses.  In particular, they must not make any	
  assumptions regarding the syntax or properties of those addresses	
  (e.g., the existence and location of embedded IPv4 addresses), or the	
  type of associated translation mechanism (e.g., whether it is	
  stateful or stateless).

Details and links from the IETF Secretariat's announcement:

Name:		draft-anderson-v6ops-v4v6-xlat-prefix
Revision:	01
Title:		64::/16: An IPv4/IPv6 translation prefix
Document date:	2016-06-21
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-anderson-v6ops-v4v6-xlat-prefix-01.txt
Status:         https://datatracker.ietf.org/doc/draft-anderson-v6ops-v4v6-xlat-prefix/
Htmlized:       https://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-v4v6-xlat-prefix-01

Abstract:
   This document reserves the IPv6 prefix 64::/16 for use with IPv4/IPv6
   translation mechanisms.

Tore

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Eric Vyncke (evyncke | 15 Jun 12:50 2016
Picon

Asking for a review of draft-ietf-opsec-v6-08

The authors (and OPSEC WG chairs) would really appreciate if a review of https://tools.ietf.org/html/draft-ietf-opsec-v6-08 is done in the coming days/weeks (in time to submit a -09 in case it needs to be amended).

This I-D is about the operation security considerations when operating an IPv6 network (both as Service Provider and enterprise/subscriber).

Thanks a lot in advance for your review and be sure to include opsec <at> ietf.org in your reply.

- the authors (Merike, KK and Eric)
- the chairmen (Gunter and Eric)

PS: Markus, Fred, Fernando and Lee, as you kindly volunteered to review it during IETF-95, I also put your names ;-)



_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Picon

v6ops - Update to a Meeting Session Request for IETF 96


An update to a meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group.

---------------------------------------------------------
Working Group Name: IPv6 Operations
Area Name: Operations and Management Area
Session Requester: Fred Baker

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 150
Conflicts to Avoid: 
 First Priority: tsvwg sunset4 rtgwg pcp ospf opsec opsawg mtgvenue dnsop aqm 6man
 Second Priority: tsvarea intarea lmap softwire

Special Requests:

---------------------------------------------------------

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Picon

v6ops - Update to a Meeting Session Request for IETF 96


An update to a meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group.

---------------------------------------------------------
Working Group Name: IPv6 Operations
Area Name: Operations and Management Area
Session Requester: Fred Baker

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 150
Conflicts to Avoid: 
 First Priority: 6man aqm dnsop mtgvenue opsawg opsec ospf pcp rtgwg sunset4 tsvwg v6ops
 Second Priority: softwire  lmap intarea tsvarea

Special Requests:

---------------------------------------------------------

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

fred | 6 Jun 17:00 2016
Picon

Call to action: post your drafts!

The Internet Draft repository will close for IETF 96 on July 8. As I
find myself reminding people each meeting, the guideline the working
group has given the chairs is that they want Internet Drafts posted,
and vetted on the list - no supporting commentary, no face time. So,
if you have a mind to write a draft for discussion in six weeks, the
time to write and post the draft is now - and then forward your posting
notification to the list explaining the issue and inviting discussion.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Mikael Abrahamsson | 3 Jun 08:11 2016
Picon

Packets with LL src and GUA dst


Hi,

I'm getting reports of people getting packets "over the Internet" with LL 
source address and GUA dst address. This seems to be a direct violation of 
https://tools.ietf.org/html/rfc4291#section-2.5.6 ?

Is there some other RFC somewhere that contradicts this or should we all 
start opening bug cases with our vendors if we see these types of packets 
forwarded to us from outside the link?

--

-- 
Mikael Abrahamsson    email: swmike@...

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops


Gmane