Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda

As I understand the proposal, this prefix would be used in ICMP but not in routing. It's a way to have ICMPv4 be able to represent an IPv6 address translated from ICMPv6. I understand that the prefix probably wants to be treated as a martian from a BGP filtering perspective, but if it's not advertised I'm not sure I see the down side in routing.

Help me out here?

On Oct 26, 2011, at 1:04 PM, Ray Hunter wrote:

> I raised concerns about draft-xli-v6ops-ivi-icmp-address-00.txt when it was originally discussed on this list last July.
> 
> The draft has not been updated since, so my concerns remain.
> 
> There now seems to be a number of people on the list who see its benefit, and are supporting the draft.
> 
> IMHO Due consideration should be made to weigh up the likely operational cost incurred because (many?) operators will have to change a lot of operational filters (to avoid the very likely abuse of this special range as a DDOS source) against the likely operational benefit for the (few?) operators who have applied this technology.
> 
> There are alternatives available for address ranges to use as a source address of translations within the AS without assigning a new global special purpose range (either RFC1918, or a privately assigned block of public IPv4 addresses from existing space, which can be shared between operators).
> 
> Admittedly the alternatives are not very attractive. But neither is the translation of ICMP messages into a packet that carries very little value or information when observed outside of its own AS, which is not traceable, and which could in fact become a danger thus triggering a need for mass packet filter updates.
> 
> I asked at the time: can anyone think of any other example of a "one-way" special purpose packet that is allowed to leave the link, never mind the AS?  RFC1918 addresses are not allowed to cross inter-enterprise links (for good reasons).
> 
> Regards,
> RayH
> 
>> Subject: Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda
>> From: Warren Kumari <warren@kumari.net>
>> Date: Wed, 26 Oct 2011 07:32:35 -0400
>> To: Xing Li <xing@cernet.edu.cn>
>> CC: "v6ops@ietf.org WG" <v6ops@ietf.org>, V6ops Chairs <v6ops-chairs@tools.ietf.org>
>> Content-Transfer-Encoding: quoted-printable
>> Precedence: list
>> MIME-Version: 1.0 (Apple Message framework v1084)
>> References: <20111013211312.B6C7421F8AFF@ietfa.amsl.com> <619C3B81-1CDC-4341-8180-EC8472864CC0@cisco.com> <4EA53FB7.6090603@cernet.edu.cn>
>> In-Reply-To: <4EA53FB7.6090603@cernet.edu.cn>
>> Message-ID: <C8B7882E-F8F0-4E65-AC5C-D8CDA24DC0EC@kumari.net>
>> Content-Type: text/plain; charset=utf-8
>> Message: 1
>> On Oct 24, 2011, at 6:36 AM, Xing Li wrote:
>> 
>>   
>>> > Hi, Fred and All,
>>> > 
>>> > 于 2011/10/14 5:52, Fred Baker 写道:
>>>     
>>>> >> The initial version of the agenda has been posted. It places v6ops on Wednesday and Friday mornings, a total of 4.5 hours. I personally am satisfied with it, but if folks have issues I can pass them along.
>>>> >> 
>>>> >> I'll note that the deadline for -00 drafts is 24 October, and the deadline for updated drafts is a week later. For discussion in the working group meetings, I'm looking for a draft posted after 25 July, with supporting email discussion on the list.
>>>> >> 
>>>> >> I'm looking for (and in some cases have seen) commentary on each of:
>>>> >> 
>>>> >> -rw-rw-r--  1 fred  fred  13796 Jul 25 23:59 draft-xli-v6ops-ivi-icmp-address-00.txt
>>>>       
>>> > 
>>> > I would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
>>> > 
>>> > The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation (192.70.192.0/24) to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
>>> > 
>>>     
>> 
>> Summary:
>> I support adoption.
>> 
>> More words: 
>> I must admit to being somewhat uncomfortable with the potential for using this space to hide that actual course of a DoS -- yes, this is somewhat addressed in the Security Considerations, but that doesn't actually remove the problem.
>> That said, the sad fact is that with so many networks not doing BCP38 you already have no faith in the source address of a packet IMO the benefits outweigh the risks.
>> 
>> W
>> 
>>   
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops