[Gen-art] Gen-art last call review of draft-ietf-softwire-public-4over6-09

[Elwyn Davies <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-softwire-public-4over6-09
Reviewer: Elwyn Davies
Review Date: 23 May 2013
IETF LC End Date: 24 May 2013
IESG Telechat date: 30 May 2013

Summary:

Major issues:
(Majorish) Purpose of the document: We only find out that this document
is a description of existing practice in CERNET2 in para 2 of section 1
(OK that is quite close to the front).  It is not recommended for future
deployments that should use the Unified CPE mechanism.  At the very
least this should be repeated in the  Abstract and be right up front in
the Introduction.  Arguably this document should be classified as
Historical rather than Informational.

Minor issues:
It would be desirable to emphasize that (I assume) 'public' is used as a
synonym for 'globally routable' or 'globally unique'. Looking closely at
RFC 1918, the term 'public address' is not used as an antonym for
'private address' (as opposed to 'private host' and 'public host'). RFC
1918 states that public hosts are expected to use 'globally unique' (and
hence 'globally routable') addresses.

Abstract, last sentence:
s/the allocation of full IPv4 address over IPv6 network/the allocation
and distribution of globally routable IPv4 addresses over the provider's
IPv6 network/

Subsequent to writing this I see from s1, para 3/4 that 'full IPv4
address' is being used as a 'term of art' meaning that the user is free
to use the address with any port number (as opposed to a
'port-restricted address').  The reader of the abstract would not
understand this implication I think. Suggest making the substitution:
NEW:
the allocation and distribution over the provider's IPv6 network of
globally routable IPv4 addresses that can be used with any port number

Since the term 'full (IPv4) address' is used several times in the
document it needs to be defined.  Perhaps I could suggest using
'unrestricted' instead of 'full' ('full' seems to imply the whole 32
bits rather than just a prefix which I don't think is the intention of
the term).

s10: This section should probably refer to the security considerations
of RFC 6333 in the case of fallback to DS-lite.

s10: Some variant of the RFC 6333 logging issue is probably needed since
the IPv4 addresses mare allocated to CEs and I suspect that there needs
to be a tie between the DHCP logging and the bindings.

s10: Is there any way for a bad actor to 'steal' a CE IPv4 address?

Does this document need a (brief) section on routing for the IPv4
addresses?  (Not sure if this is really needed).


Nits/editorial comments:
General: s/hub and spokes/hub and spoke/ (is traditional I think)

Abstract: s/When the service provider networks/When service providers'
networks/
s/uses IPv4-over-IPv6 tunnel as basic method to traverse/uses an
IPv4-over-IPv6 tunnel as the basic method for traversing/


Abstract, last sentence: Expand ICP acronym.

s1: Be consistent in use of 'user-side' or 'user side' (2 instance of
each currently).  [I think the RFC Editor will probably prefer
'user-side'.]

s1: There ought to be a reference to RFC 2473 regarding IPV4-in-IPv6
tunnelling.

s1, para 1: s/still a functionality required/still required/
s/IPv4-only/the IPv4-only/
s/this type of IPv4 services./this type of IPv4 service./

s1, para 2: Probably s/Binding approach/binding approach/ - it is only
capitalized at the start of sentences in the bmk draft.

s1, para 3: Expand ISP acronym.

s1, para 3, last sentence:
OLD:
as well as save the IPv4 address resource
    from being assigned all over the network
NEW:
as well as avoiding the need to deploy scarce IPv4 address resources
throughout the network.

s1, para 4, sentence 1: s/are developed/have been developed/

s1. para 4, sentence 3: s/Further more/Furthermore/

s1, para 4, sentence 4:
OLD:
operating system could support the mechanism smoothly, while
    transparency on upper-layer applications is guaranteed.
NEW:
in general, operating systems are able to support the mechanism
natively, while
transparency is guaranteed for upper-layer applications.

s1, para 4, sentence 5: s/which/that/

s1, para 5: s/operation/operational/, s/other: end user IPv4/other; the
end user's IPv4/ (note semi-colon instead of colon), s/in on-demand
style/in an on-demand style/, s/in the way of/being/

s1, para 6: s/IPv4-over-IPv6 tunnel/IPv4-over-IPv6 tunnelling/

s1, last para: s/are maintained/is maintained/

s2, Public 4over6:
OLD:
Public 4over6
    supports bidirectional communication between IPv4 Internet and IPv4
    hosts or customer networks in IPv6 access network, by leveraging
    IPv4-in-IPv6 tunnel and public IPv4 address allocation over IPv6.
NEW:
Public 4over6
    supports bidirectional communication between the global IPv4
Internet and IPv4
    hosts or customer networks via an IPv6 access network, by leveraging
    IPv4-in-IPv6 tunnelling [RFC2473] and public IPv4 address allocation
over IPv6.

s2, border relay:
OLD:
    4over6 Border Relay (BR): A router functioning as the border relay
in
    Public 4over6 environment. 4over6 BR is the IPv4-in-IPv6 tunnel
    concentrator located in IPv6 ISP network.  It is a dual-stack router
    which connects to both the IPv6 ISP network and IPv4 Internet.  The
    4over6 BR also works as a DHCPv4 over IPv6
    [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning public
    IPv4 address to 4over6 CEs.

NEW:
    4over6 Border Relay (BR): A router functioning as the border relay
in
    the Public 4over6 environment. A 4over6 BR is the IPv4-in-IPv6
tunnel
    concentrator located in the IPv6 ISP network.  It is a dual-stack
router
    which connects to both the IPv6 ISP network and the IPv4 Internet.
The
    4over6 BR also works as a DHCPv4 over IPv6
    [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning and
distributing a public
    IPv4 address to 4over6 CEs.

s3, para 1: Are the customer networks necessarily LANs?  'private' might
be a better term?
Expand acronym LAN (whether or not as it appears in 'home LAN').
Comment also applies to
Figure 1.

s3, para 1: s/connected to IPv4 Internet/connected to the IPv4 Internet/

s3, para 1: s/border relays/Border Relays/ (or use acronym BR that you
defined).

Figure 1: Would be a little clearer if the height of the BR box was
expanded to
7 lines so the connections to the CEs were not at the corners of the
box.

s3, para 2: Explicitly associate DS-Lite acronym with Dual-Stack Lite.

s3, para 2: s/which switches/that switches/

s3, para 2: Might be good to emphasise that you are talking about
globally
routable IPv4 address resource.

s3, para 2: s/so much/so many/

s3, para 2: Expand acronym CGN.

s3, para 2:
OLD:
    A
    typical case of the high-end users that could use Public 4over6 is
    IPv4 application server.  Full, public IPv4 address brings
    significant convenience in this case, which is important to IPv6
    transition for ICPs.  The DNS registration can be direct using
    dedicated address; the access of the application service can be
    straightforward, with no translation involved; there will be no need
    to provide NAT traversal mechanisms for incoming traffic, and no
    special handling is required for well-known ports.
NEW:
    A
    typical use case for high-end users that could use Public 4over6 is
    an IPv4 application server.  Using a full (unrestricted), public
IPv4 address brings
    significant advantages in this case, which is important for
transitioning
    ICPs to IPv:
     - The DNS registration can be direct using a dedicated address;
     - Access for clients of the application service can be
       straightforward,
       with no translation involved;
     - There will be no need to provide NAT traversal mechanisms for
       incoming traffic, and no special handling is required for
       well-known ports.

s4.1, bullet 1: s/the information of/knowledge of/, s/by DHCPv6/using
DHCPv6/ (possibly)

s4.2, para 2: s/enables DHCPv4 message/allows DHCPv4 messages/,
s/between BR and CE/between the BR and the relevant CE/,
s/to support that/needed to support this operation/

s4.2, last para:
OLD:
    While regular users would probably take DHCPv4 over IPv6, the manual
    configuration is usually seen in two cases: application server,
which
    requires a stable IPv4 address, and enterprise network, which
usually
    requires an IPv4 prefix rather than one single address (Note that
    DHCPv4 does not support prefix allocation).

NEW:
    While regular users would probably opt for DHCPv4 over IPv6, the
static
    configuration is particularly applicable in two cases: for
application servers, which
    require a stable IPv4 address, and for enterprise networks, which
usually
    require an IPv4 prefix rather than one single address (Note that
    DHCPv4 does not support prefix allocation).

s5, para 1: s/or DHCPv6 option/or via a DHCPv6 option/

s5, para 2:
OLD:
    The CE regards the BR as DHCPv4-over-IPv6
    server/relay for public IPv4 address allocation, whose IPv6 address
    is learned by the CE as described above.
NEW:
    The CE regards the BR as its DHCPv4-over-IPv6
    server/relay, which is used to obtain its public IPv4 address
allocation; its IPv6 address
    is learned by the CE as described above.

s5, para 3: s/DHCPv4 over IPv6/DHCPv4-over-IPv6/ (I think).

s5, para 4:
OLD:
    The decapsulation on 4over6 CE is simple.  When receiving
    an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and
    either hands it to upper layer or forward it to customer network
    according to the IPv4 destination address.
NEW:
    The decapsulation on the 4over6 CE is simple.  When receiving
    an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and
    either hands it to a local upper layer or forwards it to the
customer network
    according to the IPv4 destination address.

s5, para 5: Expand NAPT acronym.

s5, para 6: s/necessarily/necessary/

s5, para 7: s/4over6 CE supports/The 4over6 CE supports/,
s/employ Well-Known/employ the Well-Known/,
Expand B4 acronym,
s/for instance, the DHCPv4 over IPv6/for instance, if the
DHCPv4-over-IPv6/

s6, para 1: s/4over6 BR/The 4over6 BR/,
s/to provide correct/to provide the correct/,
s/validate/validating/

s6, bullet 1: s/collocated/co-located/ or 'colocated',
s/delete/deletes/

s6, bullet 2: Expand TRA acronym

s7/s8: RFC 6333 talks about B4 and AFTR elements:  How does this map
into the elements in this draft? In particular referring to s5.5 of RFC
6333, do both CE and BR need DNS proxies?  I am not sure that just
referencing RFC 6333 is sufficient here, but with the mapping explained
it may be  adequate.

s12: This section would normally be called 'Contributors'.

s13: I think I-D.ietf-dhc-dhcpv4-over-ipv6 is a normative reference.

s13.1: Requires a reference to RFC 2473.  RFCs 4925, 4966, 5549, and
5565 are not referenced currently.