Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt

[Philip Matthews <[e-mail]>]

Hi Mukom and everyone:

Thanks for the comments.  I am on vacation right now but Victor and I will get together in a week to work on the revision.

- Philip

On 2015-08-13, at 14:43 , Mukom Akong T. wrote:

> Table at top of page 3 states "Works" for certain choices. I think it will be effective to more specific about what 'Works' means in this context. As this document is heavily L3 focused, perhaps defining 'Works' in terms of "L3 routing and forwarding functions as expected without ....."
> 
> 
> [snip]
> 
>   +---------+------------+-------------------+------------------------+
>    |    PA   |  Tunneled  |    Works. Using   |  Works. Using private  |
>    |         |            | private addresses |    addresses likely    |
>    |         |            |   likely better   |     better option.     |
>    |         |            |      option.      |                        |
>    +---------+------------+-------------------+------------------------+
> 
> [snip]
> 
> Like Mike, I'd think some more clarifications need to be made as to why private is a better option than PA. 
> 
> - I'd rather have "works but PI is a better option" 
> - I'd be curious to know that what 
> 
> 
> On 9 July 2015 at 04:25, Mark Smith <[e-mail]> wrote:
> On 7 July 2015 at 14:48, Brian E Carpenter <[e-mail]> wrote:
> > Hi,
> >
> > I don't understand why you mention RFC 1918 in a document about
> > IPv6 deployment.
> >
> > In the table in 2.1.1, I object strongly to the comment against
> > private (i.e. ULA) addresses
> > "Will probably require some sort of NAT on links to the Internet."
> >
> > That isn't the architecture. The architecture is that nodes have multiple
> > addresses, and only use ULAs for internal traffic, and use PA or PI addresses
> > for Internet traffic.
> 
> I agree.
> 
> Unless you're using link-locals only in your network (and that isn't
> really possible for the edge networks), there is always an address
> selection process going on between the always present link-locals and
> the other address or addresses that are available.
> 
> Perhaps it isn't that common knowledge that link-local addresses are
> quite valid to be used by/for applications, as per RFC4007, and are
> normally preferred over all other address types if they're available
> to the application, excepting the loopback prefix, because link-locals
> have the second smallest scope (and the smallest scope is preferred).
> 
> In other words, most IPv6 networks are multi-prefix even if their
> operators think they aren't because they "only" have a single GUA.
> This is probably worth more visibly highlighting or emphasising in
> this draft, because it seems to be something that is commonly
> forgotten or not completely realised.
> 
> > We shouldn't be documenting any other usage of
> > ULAs. We shouldn't be making statements like this:
> >
> > "For an enterprise, the use of private address space is
> > reasonable, but the enterprise will need to use NAT44 and/or
> > NPT[RFC6296] on links to the Internet."
> >
> > We clearly can't pretend that NAT44 isn't widely used, but IMHO it should
> > be completely out of scope in this document, and NPTv6 is an experimental
> > RFC that we should never recommend. ULAs should *only* be used in parallel
> > with PA or PI. That isn't an afterthought; that is the basic intention behind
> > ULAs.
> >
> 
> I've thought that if it is unacceptable for devices inside your
> network to have global addresses, then your security requirements are
> probably so stringent that NPTv6 devices, packet filters and stateful
> firewalls would be too simple to achieve and implement them. Instead,
> you'd use application layer proxies for specific applications you
> permit, that act on behalf of and completely or near completely hide
> the identity of the devices inside your network, and prevent any
> possible reachability to those devices, inherent in ULA addressing,
> unless the application layer proxy itself is compromised.
> 
> If using per-application application layer proxies is considered too
> onerous or costly, then I think the security measures you'd have in
> place (e.g., host firewalls, network perimeter firewalls/packet
> filters) would mean there is less risk to deploying global addresses
> internally compared to the benefits of having them.
> 
> <snip>
> 
> Regards,
> Mark.
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> -- 
> 
> Mukom Akong T.
> 
> http://about.me/perfexcellence	|  twitter: @perfexcellent	
> ------------------------------------------------------------------------------------------------------------------------------------------
> “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran
> -------------------------------------------------------------------------------------------------------------------------------------------