Edwin Cordeiro | 23 May 17:24 2016
Picon

Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host

Hello all,

Below is the first review from the Internet Draft Review Team that I'm mentoring.

Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-00

Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro

Review Date: May 23th 2016

Summary: It is a good suggestion for a BCP, but it needs to add DHCP-PD to it

Comments: The draft proposes the use of an unique /64 for each user equipment connected to a WLAN gateway. The proposal highlights the benefit of such approach but fails to analyse possible consequences. I would support this draft to move forward if these issues are addressed.

Major Issues: 
- The DHCPv6-PD is mentioned for the first time only in section 4.3.1 and later at the "Future Work" session. From my understanding DHCPv6-PD is capable of implementing the network as desired in this BCP. Considering the intended status is BCP, I think that DCHPv6-PD should be added as valid implementation alternative.
- The draft doesn't mention possible issues of giving one /64 for each UE, for example, a public WIFI with support for 512 users will need a /55 instead of a single /64.

Minor Issues and Nits: 

Questions:
- Should this document address the best way to logging the prefix assign to the UE/subscriber?
- Assigning the same unique prefix if the UE/subscriber reconnect to the same AP, is something that should be considered or avoided?

Best regards,

Edwin Cordeiro
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Stephen Farrell | 4 May 10:25 2016
Picon
Picon

Stephen Farrell's No Objection on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-v6ops-host-addr-availability-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(I'm getting a bit outside my area of expertise here, but
since I've been playing about with IPv6 recently and am not
shy about asking silly questions... :-)

- I think you're missing one other reason why people
allocate /128's - in a hosting/VPS environment, the hoster
might want to avoid VPS's that originate spam using many
different source addresses over time so as to attempt to
avoid IP address based (bad) reputation accruing to their
outbound spam. Personally, I think associating such
reputation scores with IPv6 prefixes or addresses is a bit
dodgy, but this is I think something that is done in the
wild, (no idea how frequently) so would be worth a mention.
If you have good arguments as to why such a scheme is a bad
idea, that'd be good to include as well.

- I was a bit surprised to not see any mention here of
ULAs. I've seen one DHCPv6 setup where my laptop was
assigned a ULA with a very long lease in the hope of always
having that connectivity to local systems that aren't all
on the link. But having that plus real global addresses
caused glitches as (I think) my OS (ubuntu) wasn't sure
which of the addresses to use as the source for what.
While I didn't explore what was going on there (I just
zapped the lease:-), do you need to say how to handle cases
where one has both real global and ULAs on an interface? 

- I would have liked if you had said that, other things
being equal, OSes SHOULD prefer to use privacy addresses as
the source address or as a default. Is there a reason to
not say that? (Just wondering, I'm not trying to strongly
argue that you do.)

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

Suresh Krishnan | 4 May 05:14 2016
Picon

Suresh Krishnan's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT)

Suresh Krishnan has entered the following ballot position for
draft-ietf-v6ops-host-addr-availability-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3:

* What is the term ePDG being used here? Can you please add a reference?
The well known term in mobile networks is Evolved Packet Data Gateway
that is used for IPsec tunnel termination. That does not seem to make
sense here.

* Maybe worth adding a reference to RFC7278 (64share) here as an example
for "Extending the network (e.g., "tethering")."

s/which is only available in 3GPP release 10/which is only available in
3GPP release 10 onwards/

Section 4:

It is not clear what this bullet means. Can you clarify?

"  o  Uncertainty, because it is not known in advance if a particular
      operation function will be available."

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

Ben Campbell | 4 May 00:22 2016

Ben Campbell's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-v6ops-host-addr-availability-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

While I am afraid the NAT66 cats are forever out of their bag, I am still
glad to see this draft.

Section 7: I _think_ the point of this section is to suggest that we
cannot reasonably estimate an upper limit. But if it says that
explicitly, I missed it. (I fear a careless reader will walk away
thinking "20" is a good limit)

Section 8: s/RECOMMENDED to not impose a hard limit/NOT RECOMMENDED to
impose a hard limit/

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

Kathleen Moriarty | 3 May 23:37 2016
Picon

Kathleen Moriarty's No Objection on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT)

Kathleen Moriarty has entered the following ballot position for
draft-ietf-v6ops-host-addr-availability-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think the Complexity mentioned in section 4 should be a security
consideration since there are more opportunities for mistakes that lead
to data leakage.

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

Alissa Cooper | 3 May 18:27 2016
Picon

Alissa Cooper's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-v6ops-host-addr-availability-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3: s/which is only available in 3GPP release 10/which has been
made available as of 3GPP release 10/

Section 9.1: 
- May be better not to presume that operators do things "to avoid
liability" - I don't think that particular sentence is necessary here.
- I was surprised not to see a note here about interaction between this
kind of host tracking and MAC address randomization, which I assume makes
tracking harder independently of the whether the recommendations in this
document are followed. But is it not discussed because operators who feel
they need these kind of logs also prohibit MAC randomization?

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

fred | 1 May 15:00 2016
Picon

State of play

RFC Editor: AUTH48,Sent to the RFC Editor
	2016-02-29	draft-ietf-v6ops-mobile-device-profile

RFC Editor: EDIT
	2016-04-13	draft-ietf-v6ops-ipv6-ehs-in-real-world

IESG: IESG Evaluation
	2016-04-27	draft-bao-v6ops-rfc6145bis
	2016-04-01	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
	2016-01-21	draft-ietf-v6ops-unique-ipv6-prefix-per-host

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-05	draft-templin-v6ops-pdhost
	2016-01-03	draft-xcf-v6ops-chinatelecom-deployment
	2016-01-03	draft-xli-v6ops-cernet-deployment

Individual Submission: Updated 
	2016-05-01	draft-anderson-v6ops-v4v6-xlat-prefix

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

fred | 1 May 13:47 2016
Picon

new draft: draft-anderson-v6ops-v4v6-xlat-prefix

A new draft has been posted, at http://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix.
Please take a look at it and comment.

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

nalini.elkins | 30 Apr 01:52 2016

Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish

People, 

We are forming teams of new-ish people to start working together to review drafts and pose comments on the
list. 

This team has 2 people from Latin America (more will be joining over time).  They wish to study drafts in the
v6ops/ 6man/ sunset WGs.  The discussions will be conducted in Spanish or English. 

The first draft they are reading is: 

https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability

They are to read the draft and have 5 questions ready for discussion.  (They have started.) The questions can
be either things they do not understand, things they think need to be clearer in the draft or need to be
fixed. 

I would appreciate your help very much for both of the following, please let me know. 

1.  If you will be able to help them in Colombia / Argentina time zone in a webinar in Spanish or English. 
Commitment is one hour per month live and some email contact. 

2.  If you will be able to help them via email support only. 

Please help, if you can. 

BTW, a number of other teams have also started including: Spanish DNSOP, and Portugese 6lo / 6tisch / roll,
and English 6lo / 6tisch / roll.   Other groups are forming.

Thank you all very much. 

Nalini Elkins 
IETF Mentoring Team 

Inside Products, Inc. 
www.insidethestack.com 
(831) 659-8360

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

Picon

v6ops - New Meeting Session Request for IETF 96


A new 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.5 Hours
Number of Attendees: 150
Conflicts to Avoid: 
 First Priority: opsec  homenet pcp sunset4 6man aqm dnsop isis opsawg ospf tsvwg
 Second Priority: tsvarea intarea mif lmap rtgwg softwire

Special Requests:

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

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

Joel Jaeggli | 22 Apr 14:20 2016
Picon

Fw: new message

Hello!

 

You have a new message, please read http://condonetworkdc.com/management.php

 

Joel Jaeggli

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

Gmane