RE: icmpv6-v3 comments

[[e-mail]]

Pekka,

comments inline..

> Well, if we conclude that those are required, maybe we have to use  
> draft-ietf-ipsec-rfc2402bis instead -- that's already been at IESG 
> evaluation so might not end up blocking the document.

I think, we should use the latest drafts instead of the old RFCs.
I will update this in the next draft.

> PMTUD and Addr-arch would probably have to go on Informational
> section, unless we conclude that they're too strong to be used here.

I don't mind moving them to informational.  Will do that in the
next draft if no one has any objection to this.

>  
> > >     (c) If the message is a response to a message sent to 
> an address
> > >         that does not belong to the node, the Source 
> Address should be
> > >         that unicast address belonging to the node that 
> will be most
> > >         helpful in diagnosing the error. For example, if 
> the message is
> > >         a response to a packet forwarding action that 
> cannot complete
> > >         successfully, the Source Address should be a 
> unicast address
> > >         belonging to the interface on which the packet forwarding
> > >         failed.
> > > 
> > > ==> not sure if this has been implemented, so the usability 
> > > of this generic rule seems questionable.
> > 
> > Are you proposing to remove this ?  
> 
> Yes.
> 
> (But if people think mentioning some optional behaviour 
> like this is a good idea, maybe it could be reworded/
> removed in the appendix as well.)

I am fine with removing this.  If anyone is interested
in keeping this, please let me know.

> > Actually, I wanted to keep the description of the codes in 
> the numerical
> > order.  If this description sounds confusing, could you 
> suggest how to 
> > re-word it such that it is clearer without moving the 
> descriptions of 
> > 4, 5 and 6 before this ?
> 
> Maybe reword:
> 
>    If the reason for the failure to deliver can not be mapped 
>    to any of the specific codes listed above, the Code field 
>    is set to 3.
> 
> to:
> 
>    If the reason for the failure to deliver can not be mapped 
>    to any of other codes, the Code field is set to 3.
> 
> ?

Sounds good to me.

> > >    It SHOULD be possible for the system administrator to 
> configure a
> > >    node to ignore any ICMP messages that are not 
> authenticated using
> > >    either the Authentication Header or Encapsulating 
> Security Payload.
> > >    Such a switch SHOULD default to allowing 
> unauthenticated messages.
> > > 
> > > ==> has this even been implemented anywhere?  could maybe be 
> > > deleted?  This is completely unpractical, e.g., just consider 
> > > PMTU packets -- there is no way you'll ever be able to set 
> > > up security associations with everyone in the Internet to be 
> > > able to accept the packets :)
> > 
> > I completely agree with you that this is unpractical but it does
> > make sense to a completely paranoid administrator.  Whoever turns
> > this option ON might not be interested in using PMTU.  I don't
> > see any harm in keeping it.  We can make it a MAY from SHOULD.
> > 
> > What say ??
> 
> OK -- I'm fine with putting it in as MAY, with some 
> additional text to describe its inherent problems, 
> e.g. like:
> 
>   Note that setting up Security Associations to deal with all the 
>   required ICMP packets is a very difficult, if not even impossible, 
>   task (e.g., consider the PMTUD packets) so typically this is does 
>   not seem to be practical.

I don't agree that it is completely impractical to use IPv6 without
PMTUD.

What about:

   Note that setting up Security Associations to deal with all the 
   required ICMP packets is a very difficult task (e.g., consider 
   the PMTUD packets).  So PMTUD (and possibly some others) may not
   work if the node only allows authenticated ICMP packet.

> 
> > >    [PMTU]       McCann, J., S. Deering, J. Mogul, "Path 
> MTU Discovery
> > >                 for IP version 6", RFC1981, August 1996.
> > > 
> > >    [IPv6-SA]    Kent, S., R. Atkinson, "Security 
> Architecture for the
> > >                 Internet Protocol", RFC1825, November 1998.
> > > 
> > > ==> These, and IPsec RFCs are PS's at the moment -- can't refer.  
> > > IPsec ones are being revised though, if that helps any.
> > 
> > As I referred from the draft-ymbk-downref-01.txt, IPsec RFCs should
> > be normative.  So what should we do now ?
> > 
> > Also should we refer to the old IPsec RFCs or we should refer to the
> > updated ones ?  If we want to refer to updated ones, how do we refer
> > to them because they are still drafts.
> 
> See above.  Referring to drafts is OK as long as they don't create a 
> blockage when this work moves forward.  As the docs are already at 
> IESG and this is not, this is (hopefully!) not a problem.

Ok.

Regards
Mukesh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------