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

[Xing Li <[e-mail]>]

Hi, Ray,

Thanks for your mial.

? 2011/10/27 4:04, Ray Hunter ??:
> 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.

Yes, we have all the records of the previous mails and we will update 
the draft. Thanks.

>
> 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).

Due to the IPv4 address depletion, more and more IPv4/IPv6 translators 
are being deployed. We need a guideline for representing 
non-IPv4-translatable address as the source address in ICMP packets. 
Based on our operation experience, allocating a special IPv4 //24 is a 
reasonable choice. If we can move forward, there will be enough time for 
ISPs to update the filters.

Regards,

xing

>
> Regards,
> RayH
>
>> Subject:
>> Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda
>> From:
>> Warren Kumari <[e-mail]>
>> Date:
>> Wed, 26 Oct 2011 07:32:35 -0400
>>
>> To:
>> Xing Li <[e-mail]>
>> CC:
>> "[e-mail] WG" <[e-mail]>, V6ops Chairs 
>> <[e-mail]>
>>
>> Content-Transfer-Encoding:
>> quoted-printable
>> Precedence:
>> list
>> MIME-Version:
>> 1.0 (Apple Message framework v1084)
>> References:
>> <[e-mail]> 
>> <[e-mail]> 
>> <[e-mail]>
>> In-Reply-To:
>> <[e-mail]>
>> Message-ID:
>> <[e-mail]>
>> 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
>>
>>