Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

From: Ray Hunter <[email-masked]>
Date: Sat, 22 Oct 2011 09:46:18 +0200

Following all IMVHO and not directed at any particular participant.

I have been attempting to follow this discussion, as well as Homenet.

After reading many documents including: RFC6092, RFC6333, 
http://tools.ietf.org/html/draft-chown-homenet-arch-00, all the other 
Homenet discussion emails, 
http://tools.ietf.org/html/draft-ietf-pcp-base-16, 
http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-01

I have to admit I simply just don't get the big picture of how these 
will stack up operationally.

It seems to me that there are still many implicit assumptions being made 
that there's a nice neat stack of boxes connected together in a 
particular order, carrying out particular functions, and which isn't 
actually explicitly documented anywhere in a consistent manner

e.g.

one end user device - one CPE (owned by the ISP or the home user, 
running IPv6 firewall and IPv4 NAT+firewall) - transparent internet

one end user device - one CPE (owned by the ISP running IPv6 firewall + 
DS Lite) - one AFTR running CGN for IPv4

one end user device - one CPE (owned by the end user running IPv6 
firewall + DS Lite) - one AFTR running CGN
[the end user device then has to comply with all of the ISP's demands 
for DS-Lite and all other items in 6204bis]

So for example, an assumption is made that there'll never be double 
NATv4. Well I already have double NATv4 *within* my homenet. And I can't 
turn it off.

I just don't see anyone addressing the practical management problem that:

i) the ISP has a bunch of stuff and demands and things to configure 
(like DS-Lite, PPPoA, login passwords) that are highly technical, and 
are very ISP network infrastructure focused.

ii) the home user has a bunch of stuff and demands and things to 
configure (like the wireless ID, print serving, music serving) that are 
non-technical and very personal.

I find it extremely unlikely that an end user is going to be able to 
configure stuff like DS-Lite.
I find it extremely unlikely that an ISP is going to want to manage a 
music server and routed WiFi networks in the home.

As such I find it extremely likely that there are going to be a minimum 
of two (virtual) CPE's. One owned by the ISP and one by the home user. 
And that these devices will have to have the correct functions enabled.

I can't find a protocol anywhere that allows an end node or CPE router 
to discover the real topology stack of NAT box(es) or firewalls(s).

As such I don't see how a typical end node or other PCP client has any 
idea which PCP server to instruct to open or disable what.

Seems to me you need some sort of firewall and NAT discovery protocol, 
or you define that PCP requests should be sent from an end node / PCP 
client to the default next hop router and you then have to hope that it 
has up to date code and acts as a proxy to find the correct devices to 
instruct, or you come up with a definitive service stack of which box 
performs which function and exactly where in the Internet topology, or 
you can expect a lot of calls to the ISP service desks.

With all due respect, I realize of course that ISP's have vast amounts 
of their own operational experience, but perhaps they've been rather 
blinded by NATv4, so that they could potentially learn from the 
principles enterprises apply to their inter-connections (also learned 
through bitter operational experience), where interfaces between 
management domains typically:
- have clear management domain boundaries and service delivery point 
interfaces
- are protected and managed using secure protocols such as SSH
- generally run vanilla native protocols over a point-to-point x-over 
cable running fixed-speed fixed-duplex Ethernet at the trust boundary / 
service demarcation point
- are statically routed bi-directionally, or use NAT for return routing, 
or communicate via a single, agreed, heavily filtered, routing protocol 
e.g. BGP or OSPF
- rarely, if ever, are complex technology interfaces split across 
multiple management parties, especially if using technology such as 
serial links, tunnels, encryption, ATM, PPPoA, PPPoE etc.
- if you've got a special need beyond a vanilla requirement, you provide 
your own box with your own management.
- security functions run on devices owned and managed by the person who 
requires the security.
- transport networks are transparent and should not mix in any other 
functionality (except in a symmetrical manner e.g. tunnel in / tunnel 
out, or compression in / decompression out, from the same management 
provider).

I'm afraid that I can't find many of these principles being applied to 
the current set of documents around 6204bis/ PCP/ DS-Lite, unless of 
course you assume that there's one, and only one, CPE router (which is 
not in line with the Homenet architecture and discussions).

regards,
RayH
> From:[email-masked]  [mailto:[email-masked]] On Behalf
> >  Of james woodyatt
> >  Sent: Tuesday, October 18, 2011 2:41 PM
> >  To: IPv6 Operations
> >  Cc:[email-masked];[email-masked];
> >  [email-masked]
> >  Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
> >  
> >  
> >  
> >  On Oct 18, 2011, at 10:33 AM, Hemant Singh (shemant) wrote:
> >  
> >  
> >  
> >  	But the PCP base document needs to become a RFC ASAP
> >  
> >  
> >  
> >  The current revision, I-D.ietf-pcp-base-14 is unsuitable for the
> >  purposes described in REC-48 of RFC 6092, in my opinion.  I'm hoping
> >  that the forthcoming -15 revision will be acceptable, but I don't
> >  actually see it on the server yet, and some of the more authoritative
> >  participants in the working group are balking at being asked to
> >  consider a new revision of the draft.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 22 Oct 2011 15:26:13 -0500

Ray,

Let me try on the big picture for you.  RFC 6204 is the Basic IPv6 CE
router specification that covers ONLY a single IPv6 router in the home
for WAN and LAN properties.   After RFC 6204 was released we embarked on
a bis document to cover a two-router (connected back-to-back) scenario
and complex features that just could not get consensus for RFC 6204.
These were features such as routing, prefix delegation, multi-homing and
source-based IPv6 routing, DNS, MLD Proxy for multicast, mDNS, etc.
Recently when homenet was formed for an IETF WG, it was decided to take
the LAN section of the bis document to homenet and move IP Transition
tech in RFC form to a new rfc6204bis document so that a new version of
the Basic document could be released ASAP with IP Transition tech.  Thus
anything that is not included in the current rfc6204bis is all moved to
homenet.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ray Hunter
Sent: Saturday, October 22, 2011 3:46 AM
To: [email-masked] WG
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

e.g.

turn it off.

I just don't see anyone addressing the practical management problem
that:

regards,
RayH
> >  consider a new revision of the draft.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ray Hunter <[email-masked]>
Date: Sun, 23 Oct 2011 08:20:42 +0200

That is not reflected in the current document.

What I read in the title and abstract is a standards track document 
defining "Basic Requirements for IPv6 Customer Edge Routers" not 
"Requirements for Basic IPv6 Customer Edge Routers (Supporting Only 
Directly Connected Hosts)"

  Hemant Singh (shemant) wrote:
>>>   purposes described in REC-48 of RFC 6092, in my opinion.  I'm
>>>        
> hoping
>    
>>>   actually see it on the server yet, and some of the more
>>>        
> authoritative
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 24 Oct 2011 14:30:35 -0700

Section 3.2:

   The IPv6 CE router may be manually configured in an arbitrary
   topology with a dynamic routing protocol.  Automatic provisioning and
   configuration are described for a single IPv6 CE router only.

On Sat, Oct 22, 2011 at 23:20, Ray Hunter <[email-masked]> wrote:

> **
> "Requirements for Basic IPv6 Customer Edge Routers (Supporting Only Directly
> Connected Hosts)"
>
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf
> Of Ray Hunter
> After reading many documents including: RFC6092, RFC6333, http://tools.ietf.org/html/draft-chown-homenet-arch-00, all the other
> Homenet discussion emails, http://tools.ietf.org/html/draft-ietf-pcp-base-16, http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-01
>
>  From:[email-masked]  [mailto:[email-masked] <[email-masked]>] On Behalf
>
>
>   Of james woodyatt
> v6ops mailing [email-masked]://www.ietf.org/mailman/listinfo/v6ops
>
>
>