On 14/05/2017 05:42, Tom Herbert wrote:
> Hello,
>
> At the Chicago WG meeting I made a request that ILA be taken up as a
> WG item in int-area. The WG chairs and AD requested that we raise a
> discussion on the list about what else is needed to be done for ILA
> (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The
> question was also raised if int-area is the right WG for ILA or if it
> should have a BOF.
I think it's fine for int-area to take this up, as long as 6man
is alerted.
A few somewhat random comments:
Is there any particular reason you chose a /64 routing prefix,
rather than say /72 or /80? I don't see any dependency on SLAAC,
so there's no reason to care about /64, right? I assume you would
use DHCPv6 or some other method of assigning addresses to VMs.
If you used /72 or /80 you'd have flexibility with a ULA prefix to
insert a subnet field.
> The format of an ILA address with a global unicast locator is:
>
> |<--------------- Locator --------------->|
> |3 bits| N bits | M bits | 61-N-M | 64 bits |
> +------+-------------+---------+---------------------------------+
> | 001 | Global prefix | Subnet | Host | Identifier |
> +------+---------------+---------+--------+----------------------+
Why is this restricted to 2000::/3?
> The format of an ILA address with a unique local IPv6 unicast locator
> is:
>
> |<--------------- Locator --------->|
> | 7 bits |1| 40 bits | 16 bits | 64 bits |
> +--------+-+------------+-----------+----------------------------+
> | FC00 |L| Global ID | Host | Identifier |
> +--------+-+------------+-----------+----------------------------+
The first byte is confusing; presumably you're trying to express
fd00::/8 so why not put 11111101 ?
I agree that the flow label would be tricky to use for this sort of
purpose, but I have a couple of comments anyway:
> o The flow label is only twenty bits, this is too small to be a
> discriminator in forwarding a virtual packet to a specific
> destination. Conceptually, the flow label might be used in a
> type of label switching to solve that.
Perhaps, but 6man fairly comprehensively rejected that type of usage.
In practice it's excluded by section 4 of RFC6437.
o The flow label is not considered immutable in transit,
intermediate devices may change it.
That's not phrased quite right. RFC6437 section 2 says:
" Once set to a non-zero value, the Flow Label is expected to be
delivered unchanged to the destination node(s). A forwarding node
MUST either leave a non-zero flow label value unchanged or change it
only for compelling operational security reasons as described in
Section 6.1.
There is no way to verify whether a flow label has been modified en
route..."
You could in fact have an operational guarantee that within an
administrative domain, no middleboxes will change the flow label.
So something like this is more accurate:
o The flow label is not protected against changes in transit.
> o Intermediate devices must not insert extension headers
> [RFC2460bis].
I think you could say:
o Current specifications do not allow intermediate devices to
insert extension headers [RFC2460bis].
Regards
Brian
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
