Subject: [imss] New revision of the IPv6 over Fibre Channel draft

From: Claudio DeSanti <[email-masked]>
Date: Fri, 16 Apr 2004 17:52:06 -0700

Hi all,

I released revision -02 of the IPv6 over Fibre Channel specification to 
resolve the comments received from the IESG review. Here is a summary of 
the comments with the relative resolutions.
Thanks for the review,

                             Claudio.

------------

Russ Housley:
Comment:
[2004-04-12]
   Section 4.1 does a good job of pointing out that layer 2 and layer 3
   security protocols can be used.  This information should be repeated
   in the security considerations.
   >
   > The FC ESP_Header [FC-FS] MAY be used to secure the FC frames
   > composing the FC Sequence. [AH] or [ESP] may be used to provide
   > security at the IPv6 layer. Other types of FC Optional Header MUST
   > NOT be used in an IPv6 FC Sequence.
   >
   It would be nice to expand on this discussion in the security considerations
   section, especially in the area of layer 2 security since [FC-FS] is not as
   easy to obtain as an RFC.

Resolution: Improved the security considerations section, by changing:

    Server. All the techniques defined to secure IPv6 traffic may be used
    in a Fibre Channel Environment.

in:

    Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames
    composing FC Sequences carrying IPv6 packets. All the techniques
    defined to secure IPv6 traffic at the IPv6 layer may be used in a
    Fibre Channel environment.

Allison Mankin:
Comment:
[2004-04-14]
   I couldn't decide whether to make this a blocking comment, hence the 
record of a
   cleared Discuss.  Does this ND actually work?  Section 9 says the 
solicited-node
   address is mapped to broadcast, so there's a scaling question.  Appendix B
   has a discussion related to validating the Neighbor Solicitation 
information which is
   unreadable, because of unexplained acronyms from the FC specs, but which 
suggests
   there are complications.

Resolution: in Fibre Channel we need to use broadcast, because there is no 
standardized way to perform distribution of multicasts. Instead there are 
mechanisms to limit the distribution of broadcasts to only the involved 
nodes, and so this is not a scaling issue.
Appendix B has nothing to do with validating the Neighbor Solicitation 
information, instead it describes informatively a normal procedure each 
Fibre Channel port should perform when certain events occur, independently 
from IPv6. The sentence in section 9 which may lead to think that the 
Neighbor Solicitation information has to be verified has been improved, by 
changing:

    are required to resolve an IPv6 unicast address. The fact that the
    N_Port_ID is volatile implies that the mapping between N_Port_Name
    and N_Port_ID MUST be valid before use. Appendix B discusses the
    validation process.

in:

    are required to resolve an IPv6 unicast address. The fact that the
    N_Port_ID is volatile implies that an Nx_Port MUST validate the
    mapping between its N_Port_Name and N_Port_ID when certain Fibre
    Channel events occur (see Appendix B).

Michael Patton:
Comment:
[2004-04-14]
   In section 3, it might be nice if they explained why only those
   specific N_Port_Name formats.  This restriction is mentioned elsewhere
   as well.  Given how much explanation of the underlying technology they
   have in Section 2, this oversight seems odd.  After all, they laid the
   groundwork for all the other things on the list.  I did see some
   explanation in 6.1, with details in the rest of section 6, so the
   simple fix is just a forward reference from Section 3 to Section 6.
   Although mentioning the restriction and why it's acceptable a little
   earlier than section 3 might be nice.

Resolution: added a reference, by changing:

    - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
      0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is
      outside the scope of this specification;

in:

    - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
      0xD, 0xE, 0xF (see section 6.1). IPv6 support for other
      Name_Identifier formats is outside the scope of this
      specification;

Comment:
   The last paragraph of Section 5 talks about "mixed media" but
   everywhere else the document seems to imply that FC is one media.  So,
   I don't see what the heck this paragraph is about.  Either it's
   spurious and should be removed, or better explanation of what they're
   talking about is needed.

Resolution: added some media examples, by changing:

    For correct operation when mixed media are bridged together, the
    smallest MTU of all the media must be advertised by routers in an MTU
    option. If there are no routers present, this MTU must be manually
    configured in each node which is connected to a medium with a default
    MTU larger than the smallest MTU.

in:

    For correct operation when mixed media (e.g., Ethernet and Fibre
    Channel) are bridged together, the smallest MTU of all the media must
    be advertised by routers in an MTU option. If there are no routers
    present, this MTU must be manually configured in each node which is
    connected to a medium with a default MTU larger than the smallest
    MTU.

Comment:
   Simple typos:
   - First paragraph of intro has a comma that makes the grouping wrong.
     The comma at least should be removed, but even better would be to
     reword the single sentence paragraph as several sentences.
   - 4.1 "resulting to the" => "resulting in the"

Resolution: corrected the typos.

Brian Haberman:
Comment:
[2004-04-08]
   Section 6 - I would think that this section needs to at least say
   that the rules defined in RFC 2462 should be followed.  And any
   variations from that document need to be explicitly stated here.

Resolution: Section 6 is all about following the RFC 2462 rules, and that 
RFC is referenced in the third paragraph of section 6.1. Improved that 
paragraph, by changing:

    An IPv6 Address Prefix used for stateless address autoconfiguration
    [ACONF] of an Nx_Port MUST have a length of 64 bits.

in:

    Stateless address autoconfiguration MUST be performed as specified in
    [ACONF]. An IPv6 Address Prefix used for stateless address
    autoconfiguration of an Nx_Port MUST have a length of 64 bits.

 From me:
[2004-04-01]
By checking the references, I found that the most updated document
to refer for the LLC-SNAP header definition is:

    IEEE Std 802-2001, "IEEE Standard for Local and
    Metropolitan Area Networks: Overview and Architecture".

instead than:
    IEEE Standards for Local Area Networks: Logical Link
    Control", IEEE, New York, 1985.

The current reference:
    [IEEE-LLC]  IEEE Standards for Local Area Networks: Logical Link
                Control", IEEE, New York, 1985.

has been replaced by:
    [IEEE-LLC]  IEEE Std 802-2001, "IEEE Standard for Local and
                Metropolitan Area Networks: Overview and Architecture".

Finally, I updated my contact information with the Cisco address.

_______________________________________________
imss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss