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

[Ray Hunter <[e-mail]>]

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:[e-mail]  [mailto:[e-mail]] On Behalf
> >  Of james woodyatt
> >  Sent: Tuesday, October 18, 2011 2:41 PM
> >  To: IPv6 Operations
> >  Cc:[e-mail];[e-mail];
> >  [e-mail]
> >  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.
>